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

virtio-blkよりvirtio-scsiの方がいいらしい

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

参考サイト

VMのFreeBSD 13.0Rのrand_harvestqのCPU負荷が高い件

家鯖の消費電力がとある時点から急に増えた。その差は実に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とサーバを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負荷も消費電力も元に戻った。めでたしめでたし。

参考サイト

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