%20%E3%81%8C%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%AE%E7%8A%B6%E6%85%8B%E3%81%8C%E5%A4%89%E5%8C%96%E3%81%97%E3%81%9F%E3%81%A8%E3%81%84%E3%81%86%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%82%92%E5%8F%96%E5%BE%97%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B.png)
私たちの Wi-Fi アクセス ポイントは、10 分という非常に長い DHCP リース時間に設定されています。リースが更新されても IP アドレスは変わらないので、それ自体は問題ではありません。しかし、私は VMware Workstation を実行しており、このような短い間隔では仮想マシン内でネットワークが頻繁に切断されます。根本的な問題は vmet-natd デーモンにあります。このデーモンは、何らかのネットワーク イベントがあったことを検出し、それが再接続であると想定します。その結果、VM 内の仮想ネットワーク アダプタは「物理的に」ネットワークが切断され、その後すぐに再接続されます。そして、VM 内のすべての TCP セッションが切断されます。
現在、Xubuntu 18.04 ホスト上で VMware Workstation 15.1.0 を実行しています。
これらは、これが発生したときの syslog からのイベントです。
Jun 25 15:23:18 laptop wpa_supplicant[1039]: wlp2s0: WPA: Group rekeying completed with 6c:3b:6b:XX:XX:XX [GTK=CCMP]
Jun 25 15:26:06 laptop dhclient[6554]: DHCPREQUEST of 192.168.XXX.XXX on wlp2s0 to 192.168.XXX.XXX port 67 (xid=0x6f72XXXX)
Jun 25 15:26:06 laptop dhclient[6554]: DHCPACK of 192.168.XX.XX from 192.168.XX.XX
Jun 25 15:26:06 laptop NetworkManager[1038]: <info> [1561465566.1687] dhcp4 (wlp2s0): address 192.168.XX.XX
Jun 25 15:26:06 laptop NetworkManager[1038]: <info> [1561465566.1687] dhcp4 (wlp2s0): plen 24 (255.255.255.0)
Jun 25 15:26:06 laptop NetworkManager[1038]: <info> [1561465566.1687] dhcp4 (wlp2s0): gateway 192.168.XX.XX
Jun 25 15:26:06 laptop vmnet-natd: RTM_NEWADDR: index:4, addr:192.168.XXX.XXX
Jun 25 15:26:06 laptop NetworkManager[1038]: <info> [1561465566.1688] dhcp4 (wlp2s0): lease time 600
Jun 25 15:26:06 laptop NetworkManager[1038]: <info> [1561465566.1688] dhcp4 (wlp2s0): nameserver '192.168.XXX.XXX'
Jun 25 15:26:06 laptop NetworkManager[1038]: <info> [1561465566.1688] dhcp4 (wlp2s0): nameserver 'XXX.XXX.XXX.XXX'
Jun 25 15:26:06 laptop NetworkManager[1038]: <info> [1561465566.1688] dhcp4 (wlp2s0): nameserver 'XXX.XXX.XXX.XXX'
Jun 25 15:26:06 laptop NetworkManager[1038]: <info> [1561465566.1688] dhcp4 (wlp2s0): state changed bound -> bound
Jun 25 15:26:06 laptop dbus-daemon[1020]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.11' (uid=0 pid=1038 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Jun 25 15:26:06 laptop systemd[1]: Starting Network Manager Script Dispatcher Service...
Jun 25 15:26:06 laptop dhclient[6554]: bound to 192.168.XXX.XXX -- renewal in 267 seconds.
Jun 25 15:26:06 laptop dbus-daemon[1020]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jun 25 15:26:06 laptop systemd[1]: Started Network Manager Script Dispatcher Service.
Jun 25 15:26:06 laptop nm-dispatcher: req:1 'dhcp4-change' [wlp2s0]: new request (1 scripts)
Jun 25 15:26:06 laptop nm-dispatcher: req:1 'dhcp4-change' [wlp2s0]: start running ordered scripts...
Jun 25 15:26:06 laptop kernel: [10747.491441] userif-2: sent link down event.
Jun 25 15:26:06 laptop kernel: [10747.491445] userif-2: sent link up event.
そこにはVMware フォーラムのスレッドこれについては解決策がありません。
これを防ぐにはどうしたらいいでしょうか? Google の力では解決策を見つけることができませんでした。
これを修正する方法はいくつか考えられます。
- このようなイベントに対して特別な処理を実行するように vmnet-natd を修正します。(VMware サポートは役に立ちません)。
- vmnet-natd をネットワーク イベントを完全に無視するように構成しますが、そのようなオプションはないようです。
- カーネル/ユーザー空間 Linux ネットワーク スタックのパッチ適用/構成によって、Wi-Fi アソシエーションの再キー化または DHCP リースの延長が変更されなかった場合は、ネットワーク変更イベントを生成しません。
- カーネル/ユーザー空間の Linux ネットワーク スタックにパッチを適用/構成して、ネットワーク イベント (またはそのサブセット) を vmnet-natd に送信しないようにします。
この煩わしさを解決するための最も抵抗の少ない道を誰か教えてくれませんか?
アップデート1:VM のネットワーク アダプターは NAT モードに設定されており、VM をオフィス ネットワークに直接公開できないため、他のモードで実行することはできません。ホストの DHCP サーバーはアクセス ポイント自体であり、常に同じままです。ネットワークは Network Manager で管理されます。
答え1
記事 DHCP アドレスを使用する場合の Linux 上の VMWare Player の修正 問題を説明し、解決策を提示します。
VMwarePlayer v8+ で発生したこの問題は、次のように説明されます。
ホスト マシンのいずれかのネットワーク アダプタの DHCP アドレスが更新されるたびに、すべての仮想マシンはネットワークの切断と接続を受信し、更新ごとに約 20 秒間ネットワークが使用できなくなります。
これは、お客様のネットワークのように DHCP リース時間が短いネットワークでは特に有害であり、約 5 分ごとにすべての VM が短時間ネットワーク接続を失うことになります。
この動作は、次の場合に明確に確認できます/var/log/messages
。
Jun 25 15:26:06 laptop kernel: [10747.491441] userif-2: sent link down event.
Jun 25 15:26:06 laptop kernel: [10747.491445] userif-2: sent link up event.
記事の著者は、 すべての VMWarePlayer インストールに含まれているファイルの code-tar に含まれるファイル
userif-3
で文字列を発見しました。userif.c
/usr/lib/vmware/modules/source/vmnet-only.tar
彼が見つけたコードは次のようになりました。
965 int
966 VNetUserIfSetUplinkState(VNetPort *port, uint8 linkUp)
967 {
...
1010 LOG(0, (KERN_NOTICE "userif-%d: sent link %s event.\n",
1011 userIf->port.id, linkUp ? "up" : "down"));
1012
1013 return retval;
1014 }
次に、パッチ ファイルを作成し、次のようにコードを適用しました。
cd /tmp
tar xf /usr/lib/vmware/modules/source/vmnet.tar
patch -p0 < vmware-vmnet-only.patch
tar cf vmnet.tar vmnet-only
cp /tmp/vmnet.tar /usr/lib/vmware/modules/source/vmnet.tar
/usr/bin/vmware-modconfig --console --install-all
systemctl restart vmware ## or 'service vmware restart'
以下に彼のパッチをリストします:
-- vmnet-only/userif.c 2017-12-21 17:02:28.555820933 +0100
+++ vmnet-only.jjk/userif.c 2017-12-15 13:22:13.257724953 +0100
@@ -973,6 +973,9 @@
userIf = (VNetUserIF *)port->jack.private;
hubJack = port->jack.peer;
+ /* never send link down events */
+ if (!linkUp) return 0;
+
if (port->jack.state == FALSE || hubJack == NULL) {
return -EINVAL;
}