家鯖をFreeBSD 11.1-RELEASEにしてからVirtualBoxのネットワークがどうにもおかしい。

Windows 7 Pro. (x64)のゲストにVirtIOな準仮想化NICを差してブリッジネットワークで使ってたんだけど、いつ頃からか通信が疎通しなくなってしまった。NICそのものは正しく認識されリンクアップも正常なのだが、内向きも外向きもパケットが流れない。要はブリッジされてないっぽい。ネットワークの種類をNATにすると通信できるようになる。

実のところ、11.1-BETAの頃にはこの問題に遭遇しており、その時はVirtualBoxを旧バージョンにしたら直ったんですな。で、最近VirtualBox 5.1.28に更新したら再発したと。

自分が試した限りでは↓こんな感じ。

• VirtualBox 5.1.24 → NG（※11.1-BETAの頃は動いてたような気がしなくもない…）
• VirtualBox 5.1.26 → OK（※記憶が曖昧）
• VirtualBox 5.1.28 → NG
• VirtualBox 5.1.30 → NG

記憶が曖昧で不確かな部分があるが、少なくとも5.1.26以外は現環境でpackages入れて動かない事を確認済み。ついでに28と30は自前ビルドも試してみたけどダメだった。5.1.26は動いてた気がするんだけどー、pkgレポジトリにもローカルキャッシュにもバイナリが見当たらなく、最早試すこともできない(´・ω・｀)

フォーラムでバグチケも切られてるが、人によって動いてたり動いてなかったりでよく分からん。

丁度いい機会だしbhyveに乗り換えてみるかー？

• 221050 – emulators/virtualbox-ose: Bridged network doesn't work (11.1-RELEASE)

3回に渡ってお送りしてきたFreeBSD 11.0-RELEASEでkern.proc.pathnameに失敗してVirtualBoxが動かない問題だが、無事解決。予想通り11-STABLEで問題なく動いた。

うちのデジタルデータ保管を一手に担っている結構重要な家鯖だし、STABLEを追いかける元気もないので、早いところ11.1-RELEASE出ないかしらー。これまでのマイナーリリース間隔から見るに、まだまだ先っぽいけど……。

FreeBSD 11.0-RELEASEでVirtualBoxが起動しない問題、もといKERN_PROC_PATHNAMEのsysctlに失敗するのは、どうやらZFSが原因っぽい。ZFSのcasesensitivityないしnormalizationプロパティがデフォルト値以外になっていると、VFS絡みでうまく動かない模様。うちはnormalization=formCにしてるので、どう見てもこいつのせいです。本当にありがとうございました。

幸い、既にパッチが投稿されており、10/7付けでstableにも取り込まれているので11.1では直ると思われる。

が、それまでVirtualBoxが使えないのは地味に辛いなぁ。うちの環境では今のところVirtualBoxしか表面化してないけど、割と影響受けるソフト多いんじゃないかしら？久々にカーネルを自前ビルドしてみましょうかね。

• ⚙ D8146 implement zfs_vptocnp() using z_parent property
• Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)
• kern.proc.pathname failure while booting from zfs
  • 8/20にFrederic Chardon氏が報告してるのに誰からも相手されてなくてカワイソス(´・ω・｀) 原因が原因だけに殆どの環境では問題なかったんだろうけど…。

先日、家鯖をFreeBSD 11.0-RELEASEに更新してからVirtualBoxが動かなくなった。起動しようとするとVirtualBox: supR3HardenedExecDir: sysctl failedとエラーを吐いて終了する。sysctlに失敗するってどういうこっちゃ。

当該ソースはSUPR3HardenedMain.cppの1243行目付近で、VirtualBox自身の実行ファイルパスを取得してる部分。

# else /* RT_OS_FREEBSD */
    int aiName[4];
    aiName[0] = CTL_KERN;
    aiName[1] = KERN_PROC;
    aiName[2] = KERN_PROC_PATHNAME;
    aiName[3] = getpid();
 
    size_t cbPath = sizeof(g_szSupLibHardenedExePath);
    if (sysctl(aiName, RT_ELEMENTS(aiName), g_szSupLibHardenedExePath, &cbPath, NULL, 0) < 0)
        supR3HardenedFatal("supR3HardenedExecDir: sysctl failed\n");
    g_szSupLibHardenedExePath[sizeof(g_szSupLibHardenedExePath) - 1] = '\0';
    int cchLink = suplibHardenedStrLen(g_szSupLibHardenedExePath); /* paranoid? can't we use cbPath? */
 
# endif

何の変哲もないコードだし、特に最近変わったような雰囲気もない。原因切り分けのため、上記コードと同じ事をする簡単なテストコードをでっちあげて実行してみたら、同じように失敗する。

#include <sys/param.h>
#include <sys/sysctl.h>
#include <stdio.h>
 
int main(void)
{
    int pid = getpid();
    int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME, pid };
 
    printf("pid = %d\n", pid);
 
    size_t bufSize = 1024;
    char buf[bufSize];
    int result = sysctl(mib, 4, buf, &bufSize, NULL, 0);
    if (result < 0)
    {
        perror("sysctl");
    }
 
    return 0;
}

-------- 実行結果 --------
$ ./sysctltest
pid = 66245
sysctl: No such file or directory

supR3HardenedExecDirでググるとprocfsをマウントし忘れてんじゃね？という投稿が出てくるが、今回の問題箇所はprocfsを不要とするための部分なのでprocfsをマウントしようがしまいが変わらない（大体今までprocfsマウントしてなくても動いてたし…）、と思いつつ藁をも掴む思いでマウントしてみたけど、やっぱり何の解決にもならなかった＼(^o^)／

portsでソースからのインストールも試みたけどビルドがコケるし、もぅﾏﾁﾞ無理。ﾘｽｶしょ…。

• [Call For Testing] VirtualBox for FreeBSD!
• [vbox-dev] [patch] FreeBSD without procfs
• VirtualBoxが起動しなかった | サーバいじくり雑記

FreeBSD 10.1-RELEASEな自宅ファイルサーバからMacにファイルをコピーすると「予期しないエラーが起きたため、操作を完了できません（エラーコード -50）。」が発生してコピーに失敗する現象に長らく苦しめられていた。経験的にファイルサイズが大きいほど発生確率が高く、数百MBくらいまでのファイルなら問題ないが、2GBを超えるとまずアウトっていう。鯖→Macの場合AFP(Netatalk 3.1.7)でもCIFS(Samba 4.2.5)でも発生し、鯖→Windowsの場合は言うまでもなくCIFSしか使えないが、所々詰まりながらも一応成功するといった具合。

失敗時はNetatalkのログに「Cannot allocate memory」が必ず記録されている。発生場所は大体{fork.c:913} (error:AFPDaemon): afp_readか{dsi_stream.c:424} (error:DSI): dsi_stream_read_fileのどっちか。メモリたんねーと言われましても、32GB積んでるtopで見ても余裕のよっちゃんイカで数GBレベルで残ってますし…。もう全くわけがわからないよ！本格的に原因を探ろうとsshで各種情報をモニタリングしながらコピーしたら、今度はsshdまでCannot allocate memory吐いて接続切れるし……。

ドライバの不具合？NIC/L2SW由来の不具合？？もしかしてケーブルが腐ってる？？？などなど、疑心暗鬼ロードを爆走していたが、ようやく、ついに！遂に！！原因がわかったッ！！！！

犯人はヤス何とVirtualBox。 VirtualBox実行中はnetgraph関連のメモリが不足しやすく？なるっぽい。ここやここで同症状が報告されており、/boot/loader.confにnet.graph.maxdata=65536を追加すればおｋと書いてあった。

このカーネルパラメータはnetgraphのデータキューの最大確保数を表すものらしい。同様に非データ用のnet.graph.maxallocなんてのもある。それぞれ/usr/src/sys/netgraph/ng_base.cで定義されていて、コメントが若干怖いことが書いてあった。

static int maxalloc = 4096;/* limit the damage of a leak */
static int maxdata = 512;  /* limit the damage of a DoS */

下手に大きくすると問題発生時に被害が拡大しそうな雰囲気。ま、外部公開してなきゃそんなに気にしなくてもいいだろうけど。

ついでにdmesgにLimiting open port RST response from 208 to 200 packets/sec.なるログも出ていたので、/etc/sysctl.confに以下を追加。

net.inet.icmp.icmplim=2000

肝心のloader.confも一応。

net.graph.maxdata=65536
net.graph.maxalloc=65536

上記設定で1～6GBほどのファイルを100GB分くらいコピーしてみたら、何の問題もなく完了した。普通に動くって素晴らしい。

• Network problems while running VirtualBox
• Write failed: Cannot allocate memory
• (FreeBSD) bacula-fdが ERR=Cannot allocate memory というエラーを出す - ttt
• NETGRAPH(4) - 特殊ファイル - YOS OPENSONAR
• apache負荷対策 | ガイドミー管理者日記