このページの翻訳:
ソースの表示
管理最近の変更サイトマップ

メインPCとサーバをP2VしてRyzenおじさんからHaswellおじさんになった

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

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

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

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

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

変更前 変更後
CPU Xeon E5-2648Lv3 (1.8GHz/12C/24T) ×2 Xeon E5-2673v3 (2.4GHz/12C/24T) ×2
SSD PM983 960GB ×2 PM963 1.92TB ×2
HDD WD80EMAZ ×2 (ミラー)
色々8TB ×4 (RAID-Z)
ST10000NM0086 ×5 (RAID-Z2)

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

CPU Ryzen 7 1700
M/B X370 SLI Plus
RAM DDR4-3200 16GB×4 = 64GB
GPU GeForce RTX 2070 SUPER
SSD WD Black SN750 500GB (NVMe)
SSD 東芝 THNSNJ960PCSZ 960GB (SATA)
NIC ConnectX-3 Pro EN

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

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

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

(2021-03-30 追記)

改めて第10世代Coreと2070 SUPERなマシンを触ってみたら、ブラウザの表示がチョッパヤで驚いた…。P2V後のもたつきは気のせいではなかった。リンクをクリックした際、前者はまさにパッと表示が切り替わるのに対し、後者はわずかな空白期間があってからパッと出る感じ。

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スピンダウン) 100W 40W 140W
待機(HDD×6スピンアップ) 130W 170W
新サーバ 待機(HDDスピンダウン) 120W - 120W
待機(HDD×6スピンアップ) 140W 140W

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

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

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

  • GPUパススルー
    • ネットに転がってる解説記事に従って難なく可能
      • 一部記述が古かったり、曖昧だったりする箇所があるのは要注意
    • プライマリディスプレイが4kモニタだと、EFIからOSに制御が移った時にコケる。WUXGAモニタだと問題なし。
      • 仮想マシンの仮想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だと問題なし。
      • VFとLinux Bridge (vmbr0)にぶら下がっている仮想NICの間で疎通できないかも?
  • USBパススルー
    • マザボのUSBコントローラをPCIパススルーでも行けるが、後付けしたUSBカードをパススルーする方が無難。
      • (IPMIの)KVMの入力がパススルー先のVMに持っていかれ、KVMが用を成さなくなるから。
        • 仮想マウスと仮想キーボードは内部的にUSB接続されているのだ。
        • いざという時に困る(PVEのWeb UIが応答しなくなって、物理ターミナル経由でrebootしなきゃいけないときとか)
      • マザボのUSBはPCIデバイス的にはUSB 2.0/3.0が別々に認識され、片方のみパススルー設定できるが、結局両方ともパススルーされる模様。
  • スリープ、ダメ、ゼッタイ
    • VM(のWindows)をスリープさせたが最後、復帰できなくなるのでスリープさせてはいけない。
      • 少なくともパススルーしてるUSBマウス・キーボードをガチャガチャでは復帰せず
      • PVEの管理画面から何か叩けば行けるかも?
    • モニタのスリープは大丈夫。
1)
Forwarding Database Entry

PVEのWindows 10ゲストでSR-IOVのVFが動いた!

Proxmox VE 6.3とConnectX-3を使って、ゲストのWindows 10 ProfessionalでSR-IOVのVirtual Functionが動いたぞー!デバイスマネージャで認識させるところまでは楽勝だったが、何度ドライバ当て直してもエラーコード43で動かなくて随分苦労した。結局、PVEのビルトインドライバが古かったのが原因だったけど、それはまた後日。

見せてもらおうか、SR-IOVの性能とやらを!

物理マシンのWindows 10と、PVE上の仮想マシンのWindows 10をConnectX-3の40GBASE-SR接続した環境で、MS謹製ネットワーク性能測定ツールNTttcpを使い速度を測った。物理マシンが送信側、VMが受信側とした結果は下図のとおり。

右下のアクティブなタスクマネージャが物理側で、他のウィンドウはリモートデスクトップ経由のVM側だ。26Gbpsほど出ているのがわかる。同じ条件でVM側をvirtio-netとすると12Gbps程度だった。速度も然ることながらPVEのCPU負荷が段違いなので、さすがSR-IOV。

なお、最大瞬間風速で32Gbps程度出ることは確認した。

Proxmox VEのKSMを止める

Proxmox VE 6.2で仮想マシンを起動した途端、CPUファンが唸りを上げ、消費電力が50Wも増える状況に遭遇した。ゲスト側は完全にアイドル状態にもかかわらずだ。

こりゃ何事とホストでtopしてみると、ksmdなるプロセスがCPUを70~80%喰っていた。

ksmdの正体はKernel Samepage Mergingデーモンで、複数VMの同一内容のメモリページを共有して実メモリの消費量を抑える役割を担っているようだ。確かにこれはCPUリソースを食いそうだ。

メモリは潤沢にありオーバーコミットの予定もないので、お役御免ってことで無効化してしまう。同一バージョンのゲストOSを大量に起動するような状況じゃないと、イマイチ効果が薄そうな気もするし。

# systemctl disable ksmtuned

公式の解説では、その後ホストを再起動の指示があるが、systemctl stop ksmtunedでも同じ効果あるんじゃないかしら。知らんけど。KSMが効きまくってる環境だとヤバそうな気もするので、素直に再起動しときましょうか。

KSM無効後はCPU負荷も消費電力も元に戻った。めでたしめでたし。

参考サイト

FreeBSD 12.1のvirtioドライバはバグってるっぽい?

FreeBSD 12.1-RELEASEのvirtioドライバは何かしら不具合があるようだ。仮想環境のゲストとして動かした際に、virtio経由のデバイスが認識されなかったり正しく動かなかったりする模様。もしかすると、12.0-RELEASEや11.3でも同様かも。

このところProxmox VEにお熱で、自宅のFreeBSDサーバをP2Vすべく調査や実験を行っている。P2Vと言ってもPCIパススルーやRaw Device Mappingなどを使い、本来の仮想化とは少々毛色が違うのだが、この構成にしとけばいつでもV2P出来るというメリットがある。

そんなわけで、起動ディスクのNVMe SSDをPCIパススルーし、VMを起動して無事FreeBSDの起動シーケンスが流れてktkrと思ってたら、忌まわしき「Mounting from zfs:zroot/ROOT failed with error 5.」で止まってしまった。

ZFSでこのエラーになってしまったら、ここから復旧できる見込みはまずない。

仕方ないのでProxmoxやVMの設定、KVMのパススルーまわりのあれこれの見直し、FreeBSD側の/boot/loader.confのチェックにzpool.cacheの再生成など、知る限りのあらゆることを試しても症状は変わらず。

起動メッセージをよーく確認すると「ptnetmap-memdev0: cannot map I/O space」「device_attach: ptnetmap-memdev0 attach returned 6」がチラホラ出ていた。

それらしい単語でググるとVirtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTSがヒットした。試したVMは確かにQ35で作ってるし、自分と同じくルートプールが見つからなくて起動できない報告もあるし、このバグを踏んだか?

スレを読んでも修正されたんだかされてないんだか分らなかったが、ふと、先行実験でパススルーしたNVMe SSDにインストールした12.2-RELEASEは問題なく起動してたのを思い出した。それならばってことで、いったん通常環境でFreeBSDを起動し、12.2-RELEASEに更新。その後、改めてVMの方で試したら何事もなかったかのように動いた。マジかよ…(ヽ'ω`)

参考サイト

Proxmox VE 6.2とX10DRiとR7 430でGPUパススルーできた

念願のGPUパススルーができたので、記録として書き止め。環境は以下のとおり。

  • Proxmox VE 6.2-4
  • X10DRi
  • Xeon E5-2648Lv3 (VMに4コア割り当て)
  • Radeon R7 430
  • Windows 10 (20H2/x64)

ググれば出てくる方法で、何の苦労もなくできた。記念にDQXベンチVer.1.51の結果をペタり。

最高品質、1920×1080の設定でスコア7256のとても快適の評価となった。Twitterから同スコアを拾ってくると4700、7800、8000、8600、9400って感じでバラついてて何とも言えない所ではあるが、GPUパススルーのオーバーヘッドはそれほど大きくはなさそう。

ついでにリモートデスクトップ経由でベンチした結果はこちら。

これでメインマシンをサーバに収容する計画が一歩前進だなー。実現した場合、Ryzen 3.0GHzおじさんからHaswell-EP 1.8GHzおじさんへと大幅退化することになるわけだが…。H11SSL-iとEPYCほすぃ……。

start.txt · 最終更新: 2019-08-19 02:45 by Decomo
CC Attribution-Noncommercial-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0