住環境が変わって、メイン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自体は起き上がるようだが、やはり画面が出ない。
  • モニタのスリープは大丈夫。

SuperWorkstation 7048A-T (SuperChassis 743TQ-1200B-SQ)で使われているファンの備忘録。

• CPUファン (SNK-P0050AP4)
  • Nidec UltraFlo T92T12MS3A7-57T07
    • 92mm角 25mm厚
    • 12V 0.35A
    • 7枚羽
    • 型番の命名規則から読み解くと、NBRXタイプの回転数カスタム仕様のSupermicro向け特注品っぽい。
• 背面ファン
  • Nidec UltraFlo T92T12MHA7-57T071
    • 92mm角 25mm厚
    • 12V 0.14A
    • 7枚羽
    • NBRXタイプ/高回転数/特注品
• 前面ファン
  • FAN-0104L4
  • SanAce 80 9S0812P4F051
    • 80mm角 25mm厚
    • 12V 0.13A
    • 7枚羽
    • 2800RPM/24dBA/32.9CFM
  • コネクタはMolex 51191シリーズの4ピン（51191-0400）

色々と事情があって、FreeBSDで作ったHDD×4台からなるRAIDZプールを、HDD×3でデグらせた状態でZoL環境でインポートした。

すると自動scrubが走るわけだが、処理途中で一旦エクスポートし、FreeBSDの方でHDD×4の状態でインポートしようとしたら出来なかった。

# zpool import zdata
cannot import 'zdata': no such pool available

こんなエラーが出るわけ。プールをFreeBSDとLinuxの間で、あまつさえデグレった状態で行き来させたせいで壊れた！？と超焦るわけ。

ZoL環境だと正常にインポートできたのでプールの無事は確認でき、HDD×4に戻してRAID修復が終わるのを待ったところ、FreeBSDの方でも何事もなくインポートできるようになった。

ここから分かることは、どうやらデグレった状態のプールを一度でもインポートすると、プールの健全性が回復するまで別のシステムでのインポートができなくなるらしい？これがZFSの正常な挙動なのか、FreeBSD (Legacy ZFS)とZoLを行き来したが為の特殊挙動なのかは分からない。

もし正式挙動だとしたら、プール修復中にマシンが壊れるとプールが死ぬわけだから、正式挙動ではないとは思うんだけど、実際に起こった事象として記録しておく。

複数のHDDを抜き差ししてると、どのHDDがどのzpoolの構成員か分からなくなる事がある。ちゃんと管理しとけって話だが、そんな時はzdb -lでZFSのラベル情報を表示すればよい。

ProxmoxVE (ZFS on Linux)での実行なので、デバイス名はsdXになっている。

# zdb -l /dev/sdh1
------------------------------------
LABEL 0
------------------------------------
    version: 5000
    name: 'zdata'　★これ
    state: 0
    txg: 23527188
    pool_guid: 15920220212014191793
    hostid: 1525007054
    hostname: 'hostname.example.com'
    top_guid: 1118325231086088749
    guid: 9773797371878116701
    vdev_children: 1
    vdev_tree:
        type: 'raidz'
        id: 0
        guid: 1118325231086088749
        nparity: 1
        metaslab_array: 34
        metaslab_shift: 37
        ashift: 12
        asize: 31989740601344
        is_log: 0
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 3334618698730764157
            path: '/dev/ada5p1'
            phys_path: 'id1,enc@n3061686369656d31/type@0/slot@3/elmdesc@Slot_02/p1'
            whole_disk: 1
            DTL: 291
            create_txg: 4
        children[1]:
            type: 'disk'
            id: 1
            guid: 4503436449772901953
            path: '/dev/ada3p1'
            phys_path: 'id1,enc@n3061686369656d31/type@0/slot@1/elmdesc@Slot_00/p1'
            whole_disk: 1
            DTL: 290
            create_txg: 4
        children[2]:
            type: 'disk'
            id: 2
            guid: 9773797371878116701
            path: '/dev/ada2p1'
            phys_path: 'id1,enc@n3061686369656d30/type@0/slot@3/elmdesc@Slot_02/p1'
            whole_disk: 1
            DTL: 289
            create_txg: 4
        children[3]:
            type: 'disk'
            id: 3
            guid: 1033141966906037929
            path: '/dev/ada4p1'
            phys_path: 'id1,enc@n3061686369656d31/type@0/slot@2/elmdesc@Slot_01/p1'
            whole_disk: 1
            DTL: 288
            create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
    labels = 0 1 2 3

注目すべきはnameの項目で、プール名がそのまんま入っている。さらに他の項目からプールの詳細がわかる。

• name:
  • プール名
• hostname
  • プールを作成したホスト名
• vdev_tree: type
  • プールの構成方法
• vdev_tree: children
  • vdevを構成するストレージの数
• vdev_tree: children: path
  • プール構成ストレージとして最後に認識された時のデバイスパス

これらを読み解くと、/dev/sdh1は「FreeBSDマシン²⁾hostname.example.comで作られた4台構成のRAID-Zプールzdata」の構成デバイスだった、ということが推測できる。

Proxmox VE 6.3のWindows 10ゲストでConnectX-3のSR-IOVが機能しないのは、PVE内蔵のmlx4ドライバが激古なのが原因のようだ。正確にはLinuxのインボックスドライバだが。

この状態だと、SR-IOVは有効でWindows側にVirtual Functionが生えているにもかかわらず、コード43となって、どうあがいてもデバイスが動かない。PVE側では以下のようなログが出る。

mlx4_core 0000:01:00.0: vhcr command:0x43 slave:1 failed with error:0, status -22
mlx4_core 0000:01:00.0: Received reset from slave:1

“Mellanox OFED for Linux Archived Bug Fixes”を眺めると、Internal Ref 1178129に、まさにそれっぽいバグが載っていた。

Description: Fixed an issue that prevented Windows virtual machines running over MLNX_OFED Linux hypervisors from operating ConnectX-3 IB ports.

When such failures occurred, the following message (or similar) appeared in the Linux HV message log when users attempted to start up a Windows VM running a ConnectX-3 VF:

“mlx4_core 0000:81:00.0: vhcr command 0x1a slave:1 in_param 0x793000 in_mod=0x210 op_mod=0x0 failed with error:0, status -22”

バグはIBポート、うちはEthポートという違いがあるが、状況としては極めて近い。この問題はMLNX_OFED v4.2-1.2.0.0で修正済みで、2021-02-10現在の最新版はv4.9-2.2.4.0 LTSであるから、とっくの昔に解決済みのハズである。

そんなバグに何で今更遭遇するの～？と思いきや、Linuxのインボックスドライバはなんとv4.0相当という事実が判明／(^o^)＼ Kernel.orgのBugzillaでも指摘されてるが、ガン無視の模様…。

しゃーないので自前ビルドしたら無事動いた。なんだよもう、めっちゃハマったやんけ！

それでも完全解決とはいかず、デバイスは動いているように見えるものの、なぜかパケットが流れない事がある。初期化系の何かっぽくて、何度かVMを再起動して一度通信できる状態になれば、途中で途絶する事はないのが不幸中の幸いではあるが。

もう1つ気になるのは「イーサネットの状態」のパケット数カウントが何かおかしいこと。受信パケットが常に0で、これが原因かわからんがVF経由だとiTunesでGracenoteへの接続に失敗する。virtio-netの方だと大丈夫なので、うちのネットワークがおかしい訳ではない。

SR-IOVまわりは情報があまりなくて、よう分からん。

(2021-12-07 追記)

WinOF v5.50.5400のKnown Issuesを眺めてたら、Internal Ref. 1297888にパケット数カウントがおかしい問題が思いっきり載っていた……というわけで、Windowsドライバのバグで確定。

回避策がN/Aなのでドライバ修正を待つしかないが、果たして更新されることはあるのだろうか。もうConnectX-3はLTSフェイズだしなぁ。ConnectX-4がお安く手に入ればいいんだけど。