这是一篇分析VM 虚拟机虚拟机网络vmnetX启动失败原因的文章，原因是局域网中存在与vmnetX同一网段的地址。
发表于 拉尔夫·蒙奇迈耶( Ralph Mönchmeyer)

我使用 VMware Workstation 作为管理程序来托管一些我在客户项目中需要的 MS Windows Guest。由于我不信任 Windows 系统，我有时会将这些Guest放置在我的工作站或专用服务器上的不同虚拟和隔离的仅主机网络中。在其他系统上，我在 KVM/QEMU、LXC 和 libvirt 的帮助下运行用于生产和测试的虚拟化 Linux 服务器系统。前段时间，我学会了必须更彻底地跟踪不同“本地”虚拟网络的艰难方法。由于 VMware 方面以一种相当奇特的方式受到错误配置的影响，我认为这种经历对其他人也可能很有趣。

VMware 虚拟网络的主机接口有时不可用？

整个过程恰逢我的一台 Opensuse 工作站升级。我总是有点担心这样的升级是否以及如何影响 VMware WS 安装。过去我经常遇到自动编译的问题。此外，某些模块的启动会导致次要错误。然而，在第一次测试中，VMware WS 14 在使用 Opensuse Leap 15 的系统上编译没有问题。难怪，我想，因为 Leap15 的内核版本 4.12 相对较旧。

然后我必须设置一个 Windows Guest。我在虚拟 VMware 仅主机网络中为它提供了一个 IP 地址，该网络涵盖了 C 类网络的 IPv4 地址范围。VMware 使用一种虚拟网桥来支持这样的网络；通常，将主机上的虚拟网络设备与其关联，您可以为其分配网络地址范围中的某个 IP 地址。对于 C-net，VMware 使用 yyy.yyy.yyy.1 作为主机接口上的默认值（yyy.yyy.yyy 定义 C-network）。在我的例子中，主机上的设备被命名为“vmnet6”。一开始，这个虚拟接口也按预期工作。

然而，在接下来的几天里，我注意到“vmnet6”有问题。在正常的主机配置中，VMware WS 初始化脚本（“/etc/init.d/vmware”）由 systemd 作为 LSB 服务启动。该脚本加载 VMware 模块并配置定义的虚拟网络。不幸的是，通常情况下，我的“vmnet6”接口在 Linux 主机启动后并没有直接可用。然而，一些实验表明，我可以通过一些“可疑”操作来规避这个问题：

我必须以 root 权限进入“虚拟网络编辑器”并再次***保存***已经存在的虚拟网络。然后 ifconfig 或 ip 命令征用了接口“vmnet6”——这似乎也正常工作。

当你被迫以root身份进行补救时，你会有一种奇怪的感觉…但是，我暂时忽略了这个我无法直接解决的问题。我还注意到问题并非一直发生。这应该敲响了警钟……但我太愚蠢了。直到昨天，当我需要在同一地址范围内设置另一个特殊的 MS WIN Guest时。

虚拟以太网失败

此外，我升级到 VMware WS 版本 14.1.3。Opensuse Leap 15 上 VMware WS 模块的（自动）编译再次正常工作，没有出现重大问题。但是，当我通过“/etc/init.d/vmware restart”手动（重新）启动 VMware 模块时，我看到了一条错误消息：

“虚拟以太网失败”。

此类消息让您感到紧张，因为您认为 VMware 模块存在一些真正的大问题。然而，启动我的一些 VMware Guest（不是链接到 vmnet6 的那些）证明这些Guest运行完美并且可以通过他们的和主机网络设备进行通信。但是我的“vmnet6”没有出现在“ip a s”的输出中。

部分网络文章报道了“Virtual Ethernet failed”的问题；但是没有真正的解决方案。参见例如https://ubuntuforums.org/showthread.php?t=1592977；https://www.linuxquestions.org/questions/slackware-14/vmware-workstation-unable-to-start-services-4175547448/；https://communities.vmware.com/thread/264235。

现在，我开始认真地怀疑这个问题是否以及如何与我的虚拟设备“vmnet6”的已知问题有关。一些测试很快表明，当我消除与“vmnet6”相关的仅主机网络时，错误消息消失了。然后我尝试了一个新的仅主机测试网络，其中包含一个设备“vmnet7”和一个不同的 IP 范围。此外，“虚拟以太网”也开始完美无缺。那么，“vmnet6”和/或其 IP 范围有什么问题？一些旧装置的残余垃圾？搜索配置文件没有给我更好的主意。

vnetlib 日志

一分钟后我想：也许 VMware 是对的。查看日志文件“/var/log/vnetlib”发现：

10 月 14 日 14:22:49 VNL_Load - LOG_ERR 已记录
10 月 14 日 14:22:49 VNL_Load - LOG_WRN 已记录
10 月 14 日 14:22:49 VNL_Load - LOG_OK 已记录
10 月 14 日 14:22:49 VNL_Load - 成功初始化 Vnetlib
...
10 月 14 日 14:22:49 VNL_StartService - 为 vnet 启动“桥接”服务：vmnet0
10 月 14 日 14:22:49 VNLPingAndCheckSubnet - vmware-ping 的返回值：0
...
10 月 14 日 14:22:50 VNL_CheckSubnetAvailability - 子网：xxx.xxx.xxx.xxx on vnet：vmnet2 可用
...
10 月 14 日 14:22:49 VNL_CheckSubnetAvailability - 子网：yyy.yyy.yyy.yyy on vnet：vmnet6 不可用
vmnet6 上的子网不再可用，请运行网络编辑器重新配置不同的子网
10 月 14 日 14:22:50 VNL_CheckSubnetAvailability - 子网：xxx.xxx.xxx.xxx on vnet：vmnet7 可用
10 月 14 日 14:22:50 VNL_CheckSubnetAvailability - 子网：xxx.xxx.xxx.xxx on vnet：vmnet8 可用
.....

（我已经用 xxx 和 yyy 替换了真实地址。）因此，显然 VMware 在启动时会执行一种超出本地定义的虚拟设备和网络的 ping 检查。有趣的！他们为什么要ping？

答案很简单：当您为仅主机网络设置（虚拟）内部网桥时，您可能希望保证相应主机设备（“vmnet6”）的 IP 地址不存在于可访问网络的其他任何位置- 特别是当主机专用网络的主机接口可用于主机控制的路由（和 NAT）时，否则隔离的 VMware Guest到外部世界。

地址重叠

这解决了我的问题：对计划主机的接口地址 yyy.yyy.yyy.1 的地址进行手动 ping 确实给了我一个结果。我在另一台服务器上找到了源代码，有时我会在那里使用 KVM Guest、LXC 容器和 libvirt 对不同的虚拟网络配置进行测试。不幸的是，在上次测试之后，我并没有禁用所有测试网络。由于默认的 DHCP 设置，无论何时启动，都会在测试服务器上建立地址为 yyy.yyy.yyy.1 的虚拟接口。这也解释了 VMware WS 问题并非总是发生的发现——它仅在我的物理 LAN 中的测试服务器处于活动状态时发生！

然后我真的记得我在 2016 年曾经遇到过类似的问题，同时尝试 QEMU/VMware-bridge-coupling。（参见：Opensuse/Linux – KVM、VMware WS – 美德 Brücken zwischen den Welten）。因此，我应该更清楚地了解并更仔细地计划我的“本地”虚拟实验，以避免地址与 LAN 中不同主机上的其他潜在虚拟网络重叠。

愚蠢的我… VMware WS 启动脚本绝对正确，不会在我的工作站上建立第二个地址！这会导致错误消息“虚拟以太网失败”——在我看来，它应该包含更详细的信息或对日志文件的提示。但问题显然在我这边：在将 VMware WS 用于虚拟网络时，不应考虑本地主机环境，而应考虑全局网络配置。

尽管如此，VMware 对可能的 IP 地址重叠的整个处理让我有点困惑：

尽管具有相同地址的另一个接口正在网络中的某处运行，为什么您可以通过***保存***有问题的虚拟网络再次建立主机接口？好的，当你这样做时你是 root – 但是为什么此时没有给出警告？（VMware 也可以在那里进行 ping 检查…）

第二个问题也让我很担心：为什么两个IP地址相同的设备的存在并没有导致网络更加混乱？一个原因可能是我允许 ping 但没有一般的 TCP 传输到测试服务器上的虚拟设备。并且在不同的主机上正确定义了显式路由。但是，当测试服务器启动并运行时，我可以打赌 ARP 级别的一些问题。无论如何 – 网络中的这种基本错误配置也可能导致安全漏洞，当然应该避免。

一秒钟后出现的第三个问题是：如果您想在同一虚拟化主机上的同一网络地址空间内分配 KVM/QEMU Guest和 VMware Guest IP 地址，您如何避免重叠？这种情况并不像乍一看那样牵强。这种配置的一个原因可能是欧盟 GDPR (DSGVO)：

如果您需要保证客户的机密性，但仍被迫使用标准的 MS Windows 客户端，您就会遇到问题，因为 MS 可能会以无法控制的方式将数据传输到他们自己的服务器（欧盟以外）。只需阅读您在运行标准 Win 10 客户端时签署的许可和维护协议！因此，您可能希望彻底隔离此类客户端，并且只允许与 Internet 上的某些 IP 地址进行通信（而不是与 MS 服务器）。您可以允许与同一子网中的某些（虚拟化）Linux 机器进行通信，其中一台机器可以用作具有严格过滤器的网关和外围防火墙。您可以通过将 QEMU 虚拟网桥耦合到 VMware 虚拟网桥来构建此类场景。然而与此同时，您需要完全控制双方的 DHCP 系统（除了一些脚本之外）以避免地址重叠。但这实际上很简单：VMware 端的 DHCP 控制文件位于“/etc/vmware/vmnetX/dhcpd”目录下，其中“X”代表虚拟 VMware 接口编号。在 QEMU 端，您可以在“/etc/libvirt/qemu/networks”中找到这些文件。在那里您可以控制您的 IP 分配（或者甚至不为某些特殊接口分配）。好吧，但这是另一个故事的开始。

结论

使用虚拟网络时，永远不要考虑“本地”或基于主机！始终在您的全局网络环境文档中包含本地虚拟测试网络！不要总是不假思索地接受主机接口到虚拟网络的标准地址分配。