ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × PVEとConnectX-3とWindowsでSR-IOVが使えないのはMLNX_OFEDが古いせい 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がお安く手に入ればいいんだけど。 pfSense 2.4.5 on PVE 6.3でConnectX-3のVFが認識されない SR-IOVでつよつよルータ大作戦始動! というわけで、Proxmox VE 6.3-2にpfSense 2.4.5-p1のVMを作り、ConnectX-3のSR-IOVのVFをPCIパススルーしてみたが、うまく認識されなかった😇 dmesgに「pcib1: failed to allocate initial I/O port window: 0xd000-0xdfff」「pcib1: Failed to allocate interrupt for PCI-e events」といったログが記録され、pciconf -lvしてもデバイスが出てこない。そもそもデバイスプローブでこけてるっぽい。 pfSense 2.4はFreeBSD 11.3-RELEASEベースなので、より新しいFreeBSD 12なら動くんじゃね?と12-STABLEベースの2.5開発版を試してみる。 相変わらずエラーの前者は出ているものの、無事PCIデバイスとして認識されmlxenが生えてきた。2つのVFを連番でパススルーしてるのに、なぜかmlxen0とmlxen2と識別されてて少々気持ち悪いが、まぁ良しとしよう。 mlx4モジュール自体は、pfSense 2.4.5でも2.5でもカーネルに組み込まれているようだ。 NICが使えないんじゃ話にならんので、とりあえず2.5を使う方向で。そのうち安定版が出るのは間違いないだろうし。 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程度出ることは確認した。 start.txt 最終更新: 2022-07-27 15:26by Decomo