最近の変更サイトマップ

FreeBSD 11.1-RELEASEでVirtualBoxのブリッジネットワークが動かないっぽい?

家鯖を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に乗り換えてみるかー?

参考サイト

FreeBSD 11-STABLEでVirtualBox復活(`・ω・´)

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

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

FreeBSD 11.0RでZFSの特定プロパティ条件下でkern.proc.pathnameが失敗する

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

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

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

参考サイト

FreeBSD 11.0RにしたらVirtualBoxが動かなくなった(´・ω・`)

先日、家鯖を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でソースからのインストールも試みたけどビルドがコケるし、もぅマヂ無理。リスカしょ…。

参考サイト

FreeBSDでVirtualBoxを動かしていると巨大ファイルの転送でCannot allocate memoryが出る

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.confnet.graph.maxdata=65536を追加すればおkと書いてあった。

このカーネルパラメータは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 */

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

ついでにdmesgLimiting 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分くらいコピーしてみたら、何の問題もなく完了した。普通に動くって素晴らしい。

参考サイト

start.txt · 最終更新: 2016-05-07 17:46 by decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
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