smartmontools で MegaRAID 下のHDDからSMARTを取得する ( Linux openSUSE Leap 15.2 )

この記事はopenSUSE Advent Calendar 2020 11日目の記事です。
みなさんこんにちは、HalNi こと Harukaと申します。

MegaRAIDやmdRAIDでのRAIDは、構成ディスクのSMART値の中にある”WHEN_FAILED”のフラグが立った場合にディスクの切り離し・リビルドを行います。

mdRAID、MegaRAID共に自動切り離しはしてくれるが…

しかしSMART値で言うところのC7や05、代替処理保留中のセクタ数や代替処理済のセクタ数が他のHDDでもカウントアップしていた場合、リビルド中に他のHDDが飛んでストレージがお亡くなりになることも起こり得ます（起こった）
HDDの早期交換を行うためにも、各ディスクの詳細を把握したい場合、直接ディスクのSMART値を読みに行く必要があります

しかし、以前cazydiskinfoを用いてディスクのSMART値を簡単に閲覧する方法を書きましたが、この方法ではMegaRAIDに接続されているHDD・SSDのSMART値は確認できません 汗
（本家？のCrystalDiskInfoは v8.4.0 でMegaRAIDに対応済み）
この場合、smartmontools を使用してSMART値を確認すれば解決できます。

smartmontools はHDDが提供しているSMART情報を取得するツールですが、オンボードSATAコントローラと同じ感覚でMegaRAIDに繋がっているHDDのSMART値も取得できます。

検証環境：

Supermicro X10SLL-F
MegaRAID 9266-8i
openSUSE Leap 15.2

おうちの検証（にも使う）環境
おうちサーバは大部分がopenSUSEで稼働しています

2020年10月現在のおうち環境。そろそろHDD積み鯖の世代更新をしたい

自宅のラックサーバを振り返る

2016年（学部2年）

2016年夏、一台の1Uサーバを購入したところから始まった

初めての1台は RX200 S6

動機は単純で、コスパの高いPCを探した結果ラックサーバに行きついたという
4コア8スレッド x2CPU、メモリ16GB で込み込み7000円程度で購入した記憶（5000円+送料2000円）

Aruba AP は Instant OS に無理やり書き換えても動かないよ

タイトルの通り。超駄文。

Cisco Aironetシリーズの場合、集中管理型と自律型の変換がfirmwareを入れ替えると行えるのは既知の事実である
Aruba APにも集中管理型と自律型がラインナップされており、Aruba Instant AP は自律型で動作する

Aironet 1140で味をしめた自分は、懲りずにAruba AP-105 に IAP-105 のfirmwareを無理やり流し込んでみた

はんぺんは3枚しかない、普通の学生なので…

Nexus 6 に Android 10 ( crDroid Android v6.9 ) をインストール

2021/5/4　Nexus6 が Android 11 に対応したので追記 ← NEW！！！

今回はcrDroid Android v6.9をインストールする
OSの選定理由は単純、ここで名前が多く挙がっていたため

今回の試験環境：

Nexus6 ( XT1100 )
Windows10 1909 64bit

なおPCでは E:\temp\Nexus6 に各種ファイルを置いている

作業を行うPCにSDK Platform Toolsをダウンロード、適当な場所に展開しPATHを通す
developer.android.com

そして各ファイルをダウンロード
今回は
・カスタムリカバリ TWRP 3.4.0
・カスタムROM crDroid Android v6.9
・GMS関連 OpenGApps micro-20200905
・root化用 Magisk v20.4
を使用
root化に関しては最初行わなかったが、OSを起動するとカスタムリカバリ(TWRP)が標準リカバリに強制的に戻る挙動を回避するため導入した

FortiGate で ND-Proxy を使用して IPv6 通信を行う

ND-Proxyを使用することで、WAN側で受信したRA ( Router Advertisement ) をLAN側へ転送することが可能となる
ND Proxyは RFC 4389 として2006年に策定されているが、Fortigateでは FortiOS 6.0.1 でようやく実装されている

今回はND-Proxyを使用し、FortiGate傘下のデバイスにIPv6アドレスを割り当て外部へ通信可能にする

検証環境

FortiWiFi 60D
v6.0.7 build0302

おうちForti。v6.2に上げられなくて悲しい

VMware vSphere Hypervisor 7.0 を KVM 上で動作させる ( ESXi on KVM )

自宅の仮想化基盤にはKVMを使用しているが、しばしばESXiを使用して検証が必要な場面が発生する
このような時、KVM上でESXiを動作させることが出来る

KVM側でNestを有効にさせることでESXi上でVMを稼働させることが可能になるため、ベアメタル上のESXiと変わらない環境を構築することが可能である

KVM上でESXiが動作する

今回の検証環境：

Fujitsu PRIMERGY TX200 S7
・Xeon E5 2450L x2
・RAM 96GB

openSUSE Leap 15.1
・libvirt Version 5.1.0

VMware vSphere Hypervisor 7.0.0

SPARC マシンのセットアップ ILOM Password Reset ～ Solaris 11.4 インストール ( SPARC T4-1 )

謎鯖がおうちにやってきた

なんもわからん

おうちT4-1。デカいし煩いがロマンが詰まっている

基本的な操作方法について

SPARCマシンは基本的にシリアルポートから操作を行うスタイルのため、CLIで諸々の設定を行っていく
シリアルポートからログインする場合、ログイン後まず管理モード（CLIのILOM） で表示される

sparct4 login: root
Password:
Detecting screen size; please wait...done

Oracle(R) Integrated Lights Out Manager

Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.

Hostname: sparct4

->

ILOMではサーバのステータス監視（CPU温度・ファン速度etc）やログの管理、ハードウェアの診断、電源管理 等を行うことができる
サーバを弄っているというよりスイッチやルータを弄っている気分になる

管理モードの状態で start /HOST/console するとサーバ本体のシリアルコンソールにリダイレクトされ、本体のシリアルコンソールへアクセスできる

富士通 iRMC のシリアルコンソールリダイレクトを使用する（openSUSE Leap 15.1）

サーバの多くはシリアルコンソールでのアクセスが可能となっており、富士通の場合iRMCの機能としてシリアルコンソールのリモートリダイレクションが提供されている
ビデオリダイレクションはライセンスが必要である一方、シリアルコンソールリダイレクションは基本機能として提供されている
今回はライセンスが適用されていなかった使えないPRIMERGYをリモートで管理・運用できるようにする

iRMCにはSSHでの接続用のインターフェースも存在する

今回の試験環境：

FUJITSU TX200 S7 （ iRMC S3）
BIOS Version：V4.6.5.3 R1.15.0
OS：openSUSE Leap 15.1

KVM での Live Migration 環境の構築 ( openSUSE Leap 15.1 )

この記事はopenSUSE Advent Calendar 2019 15日目の記事です．

みなさんこんにちは，HalNi こと Harukaと申します．
ライブマイグレーション（Live-Migration）とは，仮想マシンが稼働している状態で今動いているハイパーバイザから別のハイパーバイザに移動させる技術のことです．

先日某イベントで物理マシン3台を用いてKVMのライブマイグレーション環境を構築したものの，なかなか説明が出来なかったので解説の意味も兼ねつつ，KVM環境でライブマイグレーションを実行するための構築手法をまとめておきます．

今回のデモ構成はハイパーバイザNode2台，NFSサーバ1台の構成でした

ホストCPUをパススルーせずにNested KVM を動かす (openSUSE Leap 15.1)

KVMでNestする場合、CPU ModelをHost passthroughにするのが一般的である
<cpu mode='host-passthrough'>
こんな感じでOK、virshやlibvirtでCPUモデルを変えるだけの簡単なお仕事

しかしVMのマイグレーションを視野に入れた場合、ホストCPUをパススルーしてしまうと面倒なことになる

ゲスト仮想マシンを別のホスト物理マシンに移行する必要が全くないことが判明している場合、そのホスト物理マシンの CPU モデルは修正なしに単純に渡されます。
一部の仮想化データセンターには、すべてのサーバーが 100% 同一の CPU を保持していることを保証する設定のセットが含まれる場合があります。
そのような場合も、ホスト物理マシンの CPU モデルは修正なしに単純に渡されます。
しかし、さらに一般的なケースとしては、ホスト物理マシン間に CPU のバリエーションが存在することがあります。
このような CPU の混在環境では、妥協できる共通の CPU を決定する必要があります。
　　　　-- Red Hat Product Documentation

これは従来のNest環境では問題になる

CPU ModelをHost passthroughにする理由として、Nested KVMの実行にはvmxというCPUの拡張機能が必要らしい
よって仮想マシンにVMXを拡張機能として持たせてあげれば良い

今回の試験環境：

openSUSE Leap 15.1
libvirt Version 5.1.0
Intel Xeon E5-2630L