PowerEdge T330とITファームを書き込んでHBA化したPERC H330環境で、H330に接続したストレージにインストールしたProxmox VE 8.0-2を起動しようとすると、EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device pathと出て止まってしまう。マザボから生えてる内蔵SATAの方だと問題ない。

PVEのフォーラムでも同様の現象が報告されている。

• Stuck at EFI stub | Proxmox Support Forum
• Proxmox 8 boot stuck at "EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path" | Proxmox Support Forum

ZFSがらみの何かっぽくext4なら大丈夫らしい。根本的な解決策は見当たらないが、PVE 7をインストールしアップデートでPVE 8にした場合は起動するそうで、試しにやってみたら確かに問題なくPVE 8が立ち上がった。すんごい気持ち悪いんですけど。

BIOSとiDRACあたりとの相性かと思い数時間かけて頑張って更新したが、完全な無駄足になってしまった…。更新後はJava版の仮想コンソールが何故か起動に失敗すること多いし、PVEで仮想コンソールのキー入力が全く効かないわ、ACPIシャットダウンが機能しないわでマジで意味がわからん。ただの無駄足であってくれた方がなんと良かったことか……

一応PVEの動作に問題はなさそうだけど、どうしたものか。

Proxmox VEの仮想ディスクは、仮想マシンから512バイトセクタのストレージとして見える。正確にはQEMUのデフォルト挙動で、仮想環境における極々一般的な挙動なので普通に使う分には困らないし、意識すらしないだろう。

じゃあどんな時に困るかというと、物理・論理セクタサイズの両方が4096バイトの、いわゆる4KnデバイスをRDMでVMにアタッチする場合や、4Kn環境をそのままP2Vした時のディスクイメージとかで困る。例えばパーティションテーブルなんかはLBA（セクタ番号）で管理されているので「パーティション1はセクタ1～262144」という設定は、4kセクタ環境なら1GiB、512バイトセクタ環境なら128MiBのパーティションを表すことになり、だいぶマズいわけですよ。（そもそも、GPTの配置自体が“LBA 1”と規定されているのでセクタサイズが合ってないとパーティションテーブル自体が正しく認識されない。）

というわけで、仮想ディスクを4Knとして認識させるには、/etc/pve/qemu-server/VMID.confをエディタで直接編集し、args:に下記の設定を追加してやればよい。

args: -set device.scsi0.physical_block_size=4096 -set device.scsi0.logical_block_size=4096

scsi0の0の部分はSCSI IDなので任意に読み替え可能で、複数のデバイスも同様に設定が可能。SATAやvirtio-blkも行けると思うけど未確認。

説明するまでもないだろうが、物理と論理のセクタサイズをそれぞれ4096に指定してあげればよい。物理4096, 論理512にすれば512e扱いになるかも？

上記設定を行った4KnのSSD×3、512eのHDD×5をRDMしてる当方の仮想環境では、想定通りに認識されている。

$ dmesg | grep sectors
da0: 2969600MB (760217600 4096 byte sectors)
da1: 2969600MB (760217600 4096 byte sectors)
da2: 2969600MB (760217600 4096 byte sectors)
da3: 17166336MB (35156656128 512 byte sectors)
da4: 17166336MB (35156656128 512 byte sectors)
da5: 17166336MB (35156656128 512 byte sectors)
da6: 17166336MB (35156656128 512 byte sectors)
da7: 17166336MB (35156656128 512 byte sectors)
cd0: 998MB (511254 2048 byte sectors)

また一つ、どーでもよいノウハウがたまってしまった。

• Change of sectorsize | Proxmox Support Forum

PC仮想化において、ストレージコントローラの準仮想化デバイスの選択肢はvirtio-blkとvirtio-scsiの2つがある。名前のとおり前者が仮想ブロックデバイスコントローラ、後者は仮想SCSIコントローラである。

SCSIレイヤを通らない分、virio-blkの方が多少性能面では有利なようだが、以下の理由により基本的にはvirtio-scsiを使った方が良いらしい。

• virtio-blkは1ゲストあたり最大28デバイス＝28ストレージに制限される
  • virtio-blkとストレージは1:1の関係でPCIデバイスとなるので、PCIバス規格の制約を受ける。
  • 他のPCIデバイス（NICなど）との兼ね合いで、実際はより少ないデバイス数となる。
  • 対するvirtio-scsiは1デバイスで数百のストレージを扱える
• virtio-blkでは一部のストレージのエミュレーションができない（光学ドライブなど）
• virtio-blkはホットスワップ非対応
• vitrio-scsiの方が開発が活発

virtio-blkで割り当てたデバイスは、ゲストからも当然ブロックデバイス扱いとなり、例えばストレージデバイス表示コマンドなどで出てこないことが多々あるため、少しわかりにくいという個人的な感覚があったりする。

• virtio-blk vs virtio-scsi · mpolednik.github.io
• Understanding of virtio-scsi and virtio-blk - Programmer Sought
• Difference between virtio and virtio single controller types? | Proxmox Support Forum

家鯖の消費電力がとある時点から急に増えた。その差は実に30Wで明らかに誤差ではない。

FreeBSDな仮想マシンを起動すると増えるのは明白だったが、原因として思い当たることはなかった。が、ふとProxmox VEのCPU使用率グラフを見たら、FreeBSD 13.0-RELEASEに更新したタイミングでCPU利用率が大幅に上がっているのに気付いた。

FreeBSD内でtopしても特段高負荷なプロセスはなかったものの、よーく見てみるとSystemが4～5%となっており、何かがCPUを使ってるのは間違いない。そこでtop -SPでシステムの個別の状態を見てみると、rand_harvestqが定常的に1CPUの40～80%を食っていた。

プロセス名から察するに、乱数のエントロピー収穫用のプロセスである。エントロピー収穫の詳細は、手前みそながらこちら。

関連するシステム変数を見ても、特に変な個所はなさげ。しいて言えば、乱数源としてVirtIO Entropy Adapter (VirtIO RNG)とIntel Secure Key RNG (RDRAND)の2種類が使われてる点が仮想マシン特有ってところかな。

$ sysctl kern.random
kern.random.fortuna.concurrent_read: 1
kern.random.fortuna.minpoolsize: 64
kern.random.rdrand.rdrand_independent_seed: 0
kern.random.use_chacha20_cipher: 1
kern.random.block_seeded_status: 0
kern.random.random_sources: 'VirtIO Entropy Adapter','Intel Secure Key RNG'
kern.random.harvest.mask_symbolic: VMGENID,PURE_VIRTIO,PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
kern.random.harvest.mask_bin: 100001001000000111011111
kern.random.harvest.mask: 8683999
kern.random.initial_seeding.disable_bypass_warnings: 0
kern.random.initial_seeding.arc4random_bypassed_before_seeding: 0
kern.random.initial_seeding.read_random_bypassed_before_seeding: 0
kern.random.initial_seeding.bypass_before_seeding: 1

で、まぁ、色々と試してみたら、VirtIO Entropy Adapterが高負荷の原因だった。

その名の通り、VMでホスト側の乱数デバイスを使うための準仮想化デバイスなんだけど、ふつーに考えたら負荷は低くなるハズ。VirtIO RNGの乱数源は/dev/urandomにしてあるので、ブロックすることもないハズだし…。この辺、特にいじってはないんだけどなー、謎。

準仮想化で負荷が高くなっては本末転倒なので、VMからVirtIO RNGを取り除いて運用することにした。FreeBSD側ではIntel Secure Key RNGが動いてるので問題はないでしょう。

これで消費電力は無事元の水準に戻り、お財布の平和は保たれたのであった。

住環境が変わって、メインPCと自宅サーバを同じ部屋に置くことになった。

自宅サーバは無駄に高スペックだったが（といっても逸般の誤家庭の人からは鼻で笑われる程度）、ほぼ自分専用のFreeBSDなNASやNextcloudサーバ程度にしか使ってなかった。まさに性能と電気代の無駄遣い状態。それでもPCと鯖を分けていたのは、煩い鯖を居住空間内に置いときたくなかったから（っていうのと自宅鯖という物理体に憧れがあったから。）

その制約がなくなった今──ある意味、自室にサーバを置かざるを得ない最大の制約が課されたとも言えるが、マシンを分ける意義がなくなったので、統合することにしたのが2020年10月。付けっぱなしの鯖と、寝てるとき以外はほぼ付けてるメインPCを1台にまとめれば、PCがいつでも使えるようになって電気代も節約できて一石二鳥という皮算用もあった。

その後、数々の検証と困難を乗り越え、ようやくProxmox VE基盤でメインPCと家鯖の仮想化による統合が完了した。このところ、PVEや仮想化関連の更新をしまくってたのはこのせい。旧メインPCは解体の後、パーツ類はヤフオクにドナドナされ、名実ともにRyzenおじさんからHaswell-EPおじさんにダウングレードだ😇

統合にあたっては、家鯖マシンをPVE基盤に流用した。本当はEPYCに変えたかったけどお金がないのさ…。そうは言っても、メインマシンとして使うにはCPUが心許なかったのでヤフオクお安く調達。ストレージまわりも整理した。

旧メインマシンの構成は下表のとおり。

仮想化後のマシン構造は下図のとおり。

仮想化という割には、パススルーやらRDMやらで物理とがっつり密結合してる。今後収容予定のルータは、正しく仮想マシンになる予定（SR-IOVのVFを除く）。

2ヵ月ほど使った感想としては、物理環境と遜色なく使えている。ハード的な性能は旧メイン機から間違いなく下がっており、当初こそブラウザの若干のもたつきを感じこそすれど気のせいないし慣れの範疇で、今は何の不満もない。3Dのゲームも動くし、USB DAC経由でiTunes再生、NVEncも問題なし。

GPUはGeForce RTX 2070 SUPERからGTX 1650へと大幅ダウングレードしているが、これは3060への乗り換えを見越しての措置。折からのGPU不足による中古価格上昇で、2070の売却代でオトクに3060へ乗り換えるつもりだった。が、いざ蓋を開けてみると3060は微妙な感じだし、今なお2070Sの中古価格は上昇傾向だしで、正直売らなきゃよかった……。

仮想メイン環境をPVEで自動起動設定すれば、ホストマシン電源オンでゲストのWindowsも起動する。また、ゲストエージェントを入れとけば、ホストのシャットダウンも何てことはない。ゲストのブラウザからPVE管理画面を開き、ホストをシャットダウンすれば自動でWindowsのシャットダウン処理が走り、その後ホストの電源が切れる。再起動も同様だ。こうした使い勝手の面でも、物理環境と大差なくて素晴らしい。

メインマシンを仮想化する上での最大の障壁はGPUだが、Proxmox VE (KVM)を使えば難なくGPUパススルーできる。仮想BIOSの画面が物理モニタに映し出された時は妙な感動を覚えた。

USBまわりはPCIパススルーでコントローラをVMに割り当てると、普通の物理マシンの感覚で使えてよい。

今回はネットワークまわりも、SR-IOVでもって物理デバイスのように扱っている。対向のL3スイッチからはVMが直接接続されているように見え、構成的に綺麗な気がする。何よりソフトウェアブリッジを使わずに済むので、パフォーマンス的にも負荷的にも有利である。

仮想化技術さまさまですわ。

電気代削減効果はちょっと微妙かなぁ。VM起動したアイドル状態で140W程度。理想は100W切ってほしいけど、CPU 2個に32GBのRDIMM 6本、GPU/NIC/USB/U.2×2 PCIeを差してるし、むべなるかな。

※新サーバのHDDが5台ではなく6台なのは間違いではない。

一応、トータル30W程度の節電だけど、旧サーバのデータは不正確なので怪しいところ。1ヵ月で21kWh節電の計算となるが、現状目に見えて電気代が安くなったとかはない。在宅勤務でおうち時間が長くなってる影響が大きいのかも。今更ながら、140Wで1ヵ月だと100kWhか…馬鹿にならんな……。

その他、メイン機を仮想化した際に気になったこと、運用上の注意点は以下に箇条書きで。

• GPUパススルー
  • ネットに転がってる解説記事に従って難なく可能
    • 一部記述が古かったり、曖昧だったりする箇所があるのは要注意
  • プライマリディスプレイが4kモニタだと、EFIからOSに制御が移った時にコケる。WUXGAモニタだと問題なし。
    • （2022-01-12 追記) PVE 7にしたらROM-Barオンでも仮想BIOS→Windowsログイン画面の遷移も問題なくなった、
    • 仮想マシンの仮想BIOS表示→Windowsの起動ロゴまでは映るが、ログイン画面に切り替わるあたりで無信号状態になる。
    • それでもWindows自体は正常に起動している。
    • ROM-Bar (GPUのBIOS)を切ると、仮想BIOS→Windowsの起動ロゴは出なくなる代わりに、ログイン画面が出るようになる。
    • 仮想BIOSを弄ることは早々ないので、ROM-Barオフで運用。ログイン画面が出るまで真っ暗なのでちょっと不安ではあるけど。
    • GeForce RTX 2070 SUPER、GTX 1650で確認。ラデは知らん。
• ネットワーク
  • ConnectX-3のSR-IOVをパススルーで利用
    • WindowsからNICとして認識されリンクアップしているものの、パケットが流れないことがある。
      • 何度か仮想マシンを再起動すると直る。一度直ればVMを落とすまで大丈夫。
      • 多少不便だけどログイン画面で判断できるので許容内。
    • なぜかiTunesのネットワークまわりの挙動が怪しい。
      • Gracenoteに繋がらない（そもそもネットワークが繋がってない判定を食らう）
      • 別マシンからホームシェアリングで繋ぎ、切断後再接続すると接続が打ち切られ、ライブラリから表示が消える。
        • iTunesを再起動すると繋がるようになる。
      • virtio-netだと問題なし。
      • ネットワークの状態ダイアログの送受信パケット数カウンターが動いてないのが原因？
        • これ自体はドライバのバグっぽい：PVEとConnectX-3とWindowsでSR-IOVが使えないのはMLNX_OFEDが古いせい
    • VFとLinux Bridge (vmbr0)にぶら下がっている仮想NICの間で疎通できないかも？
      • vmbr0のFDB¹⁾にVFのMACアドレスが載らないのが原因らしい？
        • [SOLVED] - communication issue between SRIOV VM VF and CT on PF bridge | Proxmox Support Forum
        • 82599 VF to Linux host bridge - Intel Community
        • bridge(8) - Linux manual page
• USBパススルー
  • マザボのUSBコントローラをPCIパススルーでも行けるが、後付けしたUSBカードをパススルーする方が無難。
    • (IPMIの)KVMの入力がパススルー先のVMに持っていかれ、KVMが用を成さなくなるから。
      • 仮想マウスと仮想キーボードは内部的にUSB接続されているのだ。
      • いざという時に困る（PVEのWeb UIが応答しなくなって、物理ターミナル経由でrebootしなきゃいけないときとか）
    • マザボのUSBはPCIデバイス的にはUSB 2.0/3.0が別々に認識され、片方のみパススルー設定できるが、結局両方ともパススルーされる模様。
  • USBのパケットが途切れることがあるっぽい
    • キー入力、マウスカーソルがプチフリすることがある。地味にイラつくが致命的ではない。
    • USBサウンドがたまにプチプチ切れる。地味に（ｒｙ
• スリープ、ダメ、ゼッタイ
  • VM（のWindows）をスリープさせたが最後、復帰できなくなるのでスリープさせてはいけない。
    • 少なくともパススルーしてるUSBマウス・キーボードをガチャガチャでは復帰せず
    • PVEの管理画面から何か叩けば行けるかも？
      • (2022-01-12 追記) 管理画面からスリープ解除するとVM自体は起き上がるようだが、やはり画面が出ない。
  • モニタのスリープは大丈夫。