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がお安く手に入ればいいんだけど。

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を使う方向で。そのうち安定版が出るのは間違いないだろうし。

FreeBSD 12.0-RELEASEへの更新作業時に発覚した、システム系ディレクトリの所有者が謎の6151に書き換わってる問題の続き。

こんな感じでユーザーデータ置き場以外でroot以外が所有者のディレクトリを列挙してみた。

# find / -type d ! -uid 0 ! -path "*/home/*" ! -path "*/zdata/*" ! -path "*/zbackup/*" -print0 | xargs -0 stat -f "%u %g %N" | tee ~/non_root_owner_dirs.txt

すると、以下のディレクトリの所有者が6151になっていた。

6151 0 /etc
6151 0 /etc/mft
6151 0 /etc/mft/fwtrace_cfg
6151 0 /usr
6151 0 /usr/bin
6151 0 /usr/include
6151 0 /usr/lib
6151 0 /usr/lib/bash_libs
6151 0 /usr/lib/mft
6151 0 /usr/lib/mft/mtcr_plugins
6151 0 /usr/lib/mft/python_tools
6151 0 /usr/lib/mft/python_tools/mlxmcg
6151 0 /usr/lib/mft/python_tools/mst
6151 0 /usr/lib/mft/python_tools/mstdump
6151 0 /usr/lib/mft/tcl
6151 0 /usr/lib/mft/tcl/bin
6151 0 /usr/lib/mft/tcl/lib
6151 0 /usr/lib/mft/tcl/lib/tcl8.4
6151 0 /usr/share
6151 0 /usr/share/man
6151 0 /usr/share/man/man1
6151 0 /usr/share/mft
6151 0 /usr/share/mft/mlxconfig_dbs
6151 0 /usr/share/mft/mstdump_dbs

これらディレクトリの中を覗いてみると、いくつかのファイルも6151になっている。そして6151のやつらの大半の最終更新日が2018年11月23日だった。

書き換わってるファイル達と更新日から察するに、どうもConnectX-3のユーティリティのインストールが原因のような気がする。頼むよMellanoxさん…。

幸い、6151以外に怪しい所有者は見当たらなかったので、以下のコマンドで所有者をrootに戻して一件落着（元の所有者が本当にrootだったかどうかの確証はないけど…）

# find / -uid 6151 ! -path "*/home/*" ! -path "*/zdata/*" ! -path "*/zbackup/*" -print0 | xargs -0 chown root