これは， vExperts Advent Calendar 2023 の 24 日めの投稿です．
最後に post したのが 250 日以上前という実感も無いまま 2023 年の終わりを迎えようとしています．思い返せば去年も同じ感じ（苦笑）． 来年はきっと vExperts Advent Calendar 2023 の 1 post のみになること間違い無し！ 年一くらいはマトモなネタを書けとのご指摘もあるようですが，VMUG Meeting では「VMUG LT は LT にあらず」とお叱りを受けていますので，今日こそは超ライトな内容に留めておきます．
★ R660 触ってみた
AF-0 Profile が出てきたおかげで，うちくらいの規模でも ESA の実装が現実的になりました．2024 年度のリプレースに向けて ReadyNode を物色中なのですが，幸にも R660 の実機に触れる機会をいただけたので，壊さない程度に色々と試させてもらってます． まぁ天板くらいはみなさん開けますよね．
運用者目線での推しポイントは，なんといってもこの BOSS ！
背面から見るとこんな感じです．480GB M.2 の SSD なのですが，筐体カバーを開けずに交換できるのは大変便利！
Lifecycle Controller から RAID コントローラで BOSS を選択すると，出荷状態で RAID 1 が組まれているので，早速 ESXi 8.0 U2 を Install していきます．
iDRAC があるので，Virtual Media を使ってみます．Download してきた Dell Customized の ISO を NFS で共有し，iDRAC の "Configuration" -> "Virtual Media" から "Remote File Share" を設定します．NFS の IP address と File Pathを入力します．今回の環境は
| 項目 | 値 |
|---|---|
| NFS の IP address | 10.9.9.203 |
| 共有ディレクトリ | /OME |
| ファイル名 | VMware-VMvisor-Installer-8.0.0.update02-22380479.x86_64-Dell_Customized-A03.iso |
なので，"10.9.9.203:OME/VMware-VMvisor-Installer-8.0.0.update02-22380479.x86_64-Dell_Customized-A03.iso" と入力して "Connect" をクリック，接続できたら準備完了．iDRAC から PowerON します．
起動デバイスを Virtual CD/DVD/ISO に変更します．
あっさりと Installer が起動してくれました．Virtual Media の Remote File Share は 2 つまで設定しておけるので，別の Build Image を再 Install して検証する際には便利ですね．
vSAN ESA 導入に向けた課題のひとつはネットワーク．10G まで要件は緩和されていますが，やはり性能を十分に引き出すために最低でも 25G は譲りたくないので，コストも考慮して DAC 接続前提で設計しています．汎用 DAC での苦労は今年 7 月の VMUG で LT しています（「DAC ではまってみた - Kaz IGARASHI」）が，今回は Dell 社純正 DAC と S5200 なので，OS10 側で FEC 設定を明示的に入れる必要もなく拍子抜けするほどすんなりと接続できてしまいました．
# show interface ethernet 1/1/5
Ethernet 1/1/5 is up, line protocol is up
Hardware is Eth, address is c8:f7:50:f0:96:46
Current address is c8:f7:50:f0:96:46
Pluggable media present, SFP28 type is SFP28 25GBASE-CR-2.0M
Wavelength is 256
Interface index is 63
Internet address is not set
Mode of IPv4 Address Assignment: not set
Interface IPv6 oper status: Disabled
MTU 9216 bytes, IP MTU 9184 bytes
LineSpeed 25G, Auto-Negotiation on
Configured FEC is off, Negotiated FEC is cl108-rs
OMEVV の操作性など検証予定なのですが，Advent Calendar 投稿日までには纏まりそうにないので，8.0 U2 を使って別件を試してみたいと思います．
★ KB95940 の影響を確認してみた
ちょうど 8.0 U2 のみで起こる CBT 関連の事象が公開されていたので，今回用意した検証環境で，実際に影響があるのか確認してみることにしました．
Disk の "Hot Extended" 後に，CBT の QueryChangedDiskAreas API が変更されたデータを取りこぼすらしい（汗）．うちでは Backup には Rubrik を採用しているので Rubrik Cluster に検証用 vCenter を登録し，Full Backup を取得してから，対象 VM の Disk を Hot Extend してみます．Windows はライセンス買えないので Rocky9 を使います．
最初に fdisk で /dev/sda を確認しておきます．
[root@localhost ~]# fdisk -l ディスク /dev/sda: 16 GiB, 17179869184 バイト, 33554432 セクタ ディスク型式: Virtual disk 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスクラベルのタイプ: gpt ディスク識別子: 6C578988-F11A-4FD1-8563-D9FBEA346EAA デバイス 開始位置 終了位置 セクタ サイズ タイプ /dev/sda1 2048 1230847 1228800 600M EFI システム /dev/sda2 1230848 3327999 2097152 1G Linux ファイルシステム /dev/sda3 3328000 33552383 30224384 14.4G Linux LVM ディスク /dev/mapper/rl-root: 12.81 GiB, 13753122816 バイト, 26861568 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスク /dev/mapper/rl-swap: 1.6 GiB, 1719664640 バイト, 3358720 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
vSphere Client を使って稼働中 VM のディスク容量を 16GB から 32 GB まで増やします．
ディスク容量増やした後は，Rocky に戻って rescan します．
echo 1 > /sys/class/scsi_disk/0:0:0:0/device/rescan
再度 fdisk で確認すると /dev/sda は 32GiB に変わっていますが，GPT PMBR サイズ不整合のエラーが出るので対応していきましょう．
[root@localhost ~]# fdisk -l GPT PMBR のサイズが合致していません (33554431 != 67108863) が、w (書き込み) コマンドで修正されます。 GPTテーブルのバックアップがデバイスの終端にありません。 ディスク /dev/sda: 32 GiB, 34359738368 バイト, 67108864 セクタ ディスク型式: Virtual disk 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスクラベルのタイプ: gpt ディスク識別子: 6C578988-F11A-4FD1-8563-D9FBEA346EAA デバイス 開始位置 終了位置 セクタ サイズ タイプ /dev/sda1 2048 1230847 1228800 600M EFI システム /dev/sda2 1230848 3327999 2097152 1G Linux ファイルシステム /dev/sda3 3328000 33552383 30224384 14.4G Linux LVM ディスク /dev/mapper/rl-root: 12.81 GiB, 13753122816 バイト, 26861568 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスク /dev/mapper/rl-swap: 1.6 GiB, 1719664640 バイト, 3358720 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
gdisk コマンドで GPT テーブルを修正していきます．対象のディスク /dev/sda を指定して実行します．
[root@localhost ~]# gdisk /dev/sda GPT fdisk (gdisk) version 1.0.7 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Command (? for help):
"v" を打って Disk を Verify すると，ディスクの最後にあるはずのバックアップパーティションテーブルがディスクの末尾にないようです．
Command (? for help): v Problem: The secondary header's self-pointer indicates that it doesn't reside at the end of the disk. If you've added a disk to a RAID array, use the 'e' option on the experts' menu to adjust the secondary header's and partition table's locations. Identified 1 problems! Command (? for help):
"x" を打って extra functionality メニューに入り，"e" で修正，"w" で変更を書き込みます．
Command (? for help): x Expert command (? for help): e Relocating backup data structures to the end of the disk Expert command (? for help): w Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): Y OK; writing new GUID partition table (GPT) to /dev/sda. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully.
それでは OS 側に増量分を認識してもらいましょう．pvs コマンドで Physical volume(PV) を確認します．(詳細は pvdisplay で確認できます．)
[root@localhost ~]# pvs PV VG Fmt Attr PSize PFree /dev/sda3 rl lvm2 a-- 14.41g 0
14.41g の PV /dev/sda3 があり，Volume group(VG) は rl です． lvs や vgs コマンドで Logical volume(LV) の状況も見てみましょう．
[root@localhost ~]# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root rl -wi-ao---- <12.81g swap rl -wi-ao---- 1.60g [root@localhost ~]# vgs VG #PV #LV #SN Attr VSize VFree rl 1 2 0 wz--n- 14.41g 0
vgdisplay で VG rl の詳細を表示します．このままでは容量不足で LV 拡張できないので，新しい PV を作成して VG に追加します．
[root@localhost ~]# vgdisplay rl --- Volume group --- VG Name rl System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size 14.41 GiB PE Size 4.00 MiB Total PE 3689 Alloc PE / Size 3689 / 14.41 GiB Free PE / Size 0 / 0 VG UUID PW3UbV-0Qvo-IcVh-VzCQ-YvRe-1GdK-16tdxC
再度 fdisk で /dev/sda を指定して新しいパーティションを作成します．
[root@localhost ~]# fdisk /dev/sda fdisk (util-linux 2.37.4) へようこそ。 ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。 書き込みコマンドを使用する際は、注意して実行してください。 This disk is currently in use - repartitioning is probably a bad idea. It's recommended to umount all file systems, and swapoff all swap partitions on this disk. コマンド (m でヘルプ):
"n" で新パーティション追加，パーティション番号は既存が 3 まであるので，4 を指定，セクタは今回追加分全て使い切ります．
コマンド (m でヘルプ): n
パーティション番号 (4-128, 既定値 4): 4
最初のセクタ (33552384-67108830, 既定値 33552384):
最終セクタ, +/-セクタ番号 または +/-サイズ{K,M,G,T,P} (33552384-67108830, 既定値 67108830):
新しいパーティション 4 をタイプ Linux filesystem、サイズ 16 GiB で作成しました。
コマンド (m でヘルプ):
続いて，"t" を打ってパーティションタイプを lvm に変更してから "w" で書き込み，fdisk -l で /dev/sda4 が追加されたことを確認します．
コマンド (m でヘルプ): t パーティション番号 (1-4, 既定値 4): 4 パーティションのタイプ または別名(L で利用可能なタイプを一覧表示します): lvm パーティションのタイプを 'Linux filesystem' から 'Linux LVM' に変更しました。 コマンド (m でヘルプ): w パーティション情報が変更されました。 ディスクを同期しています。 [root@localhost ~]# fdisk -l ディスク /dev/sda: 32 GiB, 34359738368 バイト, 67108864 セクタ ディスク型式: Virtual disk 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスクラベルのタイプ: gpt ディスク識別子: 6C578988-F11A-4FD1-8563-D9FBEA346EAA デバイス 開始位置 終了位置 セクタ サイズ タイプ /dev/sda1 2048 1230847 1228800 600M EFI システム /dev/sda2 1230848 3327999 2097152 1G Linux ファイルシステム /dev/sda3 3328000 33552383 30224384 14.4G Linux LVM /dev/sda4 33552384 67108830 33556447 16G Linux LVM （以下略）
/dev/sda4 を使って新しい PV を作成します．
[root@localhost ~]# pvcreate /dev/sda4 Physical volume "/dev/sda4" successfully created.
VG rl を拡張します．
[root@localhost ~]# vgextend rl /dev/sda4 Volume group "rl" successfully extended
今回増量した分全てを使って LV root を拡張します．
[root@localhost ~]# lvextend -l +100%FREE /dev/rl/root Size of logical volume rl/root changed from <12.81 GiB (3279 extents) to 28.80 GiB (7374 extents). Logical volume rl/root successfully resized.
最後に xfs_growfs コマンドでファイルシステムを拡張します．
[root@localhost ~]# xfs_growfs /
meta-data=/dev/mapper/rl-root isize=512 agcount=4, agsize=839424 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=1 inobtcount=1 nrext64=0
data = bsize=4096 blocks=3357696, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=16384, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 3357696 to 7550976
df で確認すると / (/dev/mapper/rl-root) が 29G に増えていることがわかります．Hot Extend 完了です！
[root@localhost ~]# df -Th ファイルシス タイプ サイズ 使用 残り 使用% マウント位置 devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev tmpfs tmpfs 882M 0 882M 0% /dev/shm tmpfs tmpfs 353M 5.0M 348M 2% /run /dev/mapper/rl-root xfs 29G 1.6G 28G 6% / /dev/sda2 xfs 960M 219M 742M 23% /boot /dev/sda1 vfat 599M 7.0M 592M 2% /boot/efi tmpfs tmpfs 177M 0 177M 0% /run/user/0
準備に時間かかったなぁと思いながら Rubrik で OnDemand Snapshot を実行してみました．
すると，この時点で Backup は失敗．Rubrik は既に CBT が reset されたと認識しているようで，再実行で Full backup を取得する動きになります．
拡張した sda4 めがけて数 GB ファイルを書き込んだりして何度か Hot extend , Backup & Restore を繰り返しましたが，CBT reset 検知のおかげか，Rubrik を使った環境で KB95940 に記載された事象に遭遇することはありませんでした．明示的に VM shutdown して CBT reset する必要が無い Rubrik, やはり運用者にはとても楽 & 安心です！
今回は自分の環境に影響が無いことが分かってホッとしていますが，これも全て先人が踏んでくれた Bug と，その解析 & 情報公開のおかげです．関係者のみなさんはじめ，いつも積極的に情報共有してくれる VMUG メンバーに感謝しながら，心静かに新年を迎えたいと思います．
