CentOS 7 虚拟机 NAT 网络排障：DHCP 服务为何启动即停

记一次 CentOS 7 虚拟机 NAT 网络排障：DHCP 服务为何启动即停止？

从 ifconfig 无 IPv4 地址到发现 VMware DHCP 服务配置文件丢失，记录了一次"绳子专挑细处断"的完整排障经历。

一、从 CentOS 7 虚拟机说起：网络不通的困惑

最近在搭建一个本地测试环境，用 VMware® Workstation 17 Pro（版本 17.6.1）以 NAT 模式创建了一台 CentOS 7 虚拟机。本以为网络就和"即插即用"一样简单，结果开机后一盆冷水浇下来------ifconfig 里网卡 eno16777736 只有 IPv6 地址，ping baidu.com 直接报 unknown host。

我天真的以为可能是网卡没自动启动，跑去检查 /etc/sysconfig/network-scripts/ifcfg-eno16777736，发现 ONBOOT=yes、BOOTPROTO=dhcp 都写得明明白白，配置上毫无破绽。重启网络服务、重启虚拟机，问题依旧，着实让人头疼。请教了 GPT 同志后，我开始从 DHCP 协商过程往下挖，没想到挖出来的根儿居然藏在宿主机的一个配置文件里。

二、探案过程：从 No DHCPOFFERS 到神秘消失的配置文件

原始现象

先看虚拟机里的网络状况：

bash 复制代码

[root@localhost ~]# ifconfig
eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::20c:29ff:fe7f:fedf  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:7f:fe:df  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        TX packets 38  bytes 6660 (6.5 KiB)
        ...

网卡状态 UP，但没有最重要的 inet 行（IPv4 地址）。手动执行 DHCP 请求直接暴露了问题：

bash 复制代码

[root@localhost ~]# sudo dhclient -v eno16777736
...
DHCPDISCOVER on eno16777736 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on eno16777736 to 255.255.255.255 port 67 interval 12
...
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

虚拟机已经拼命喊话（DHCPDISCOVER），但 DHCP 服务器毫无回应。这说明 DHCP 服务要么没运行，要么根本没收到广播。

步步排查

既然虚拟机配置无误，矛头自然指向宿主机侧的 VMware 服务。在 Windows 的 services.msc 里，我发现 VMware DHCP Service 的状态是"启动后停止"，手动再启一次，它闪一下就又停了。这个服务要是起不来，NAT 模式下的虚拟机绝对拿不到 IP。

这到底是为什么呢？我们来一探究竟。打开 Windows 事件查看器（eventvwr.msc），在"系统"日志里筛选 Service Control Manager 事件，一条错误记录赫然在目：

复制代码

VMware DHCP Service 服务因下列错误而停止: 
Windows 无法启动 VMware DHCP Service 服务(位于 本地计算机 上)。
错误 2: 系统找不到指定的文件。

进一步查看详细错误描述，直接给出了文件路径：

复制代码

Can't open C:\ProgramData\VMware\vmnetdhcp.conf: 系统找不到指定的文件。

根因定位

原来，VMware 的 DHCP 服务在启动时必须读取 C:\ProgramData\VMware\vmnetdhcp.conf 这个配置文件，里面定义了给虚拟机分配的 IP 地址池、子网、网关等关键信息。没了它，DHCP 服务就像一个失去导航的司机，完全不知道该怎么发 IP，于是直接罢工。

而这个文件怎么就莫名其妙消失了呢？可能是之前某次"还原默认设置"操作中断、磁盘清理工具误删，或者 VMware 升级时清理了旧配置却没有重新生成。总之，绳子专挑细处断，配置文件缺失让整个网络栈塌了一角。

三、解决方案：找回丢失的配置文件

找到了病根，解决方案就清晰了。我们可以用两种方式把 vmnetdhcp.conf 重新弄回来。

方案一：还原默认设置（推荐）

这是最安全、一键式的方法，直接让 VMware 重新生成所有缺失的虚拟网络配置文件。

完全关闭 VMware Workstation。
在 services.msc 中，将 VMware DHCP Service 设为"停止"（如果它还在挣扎）。
以管理员身份重新打开 VMware Workstation。
进入编辑 → 虚拟网络编辑器 ，点击右下角的 更改设置（赋予管理员权限）。
在列表中选择 VMnet8（NAT 模式对应的虚拟交换机）。
点击左下角的 还原默认设置 ，等待流程自动完成。VMware 会删除并重建所有虚拟网络，包括生成全新的 vmnetdhcp.conf。
回到 services.msc，手动启动 VMware DHCP Service，这时它应该能稳定保持在"正在运行"状态。
启动虚拟机，再次执行 sudo dhclient -v eno16777736 或直接 ping baidu.com，网络恢复如初。

我最终就是靠这一招搞定的，整个过程不到三分钟。

方案二：手动创建配置文件

如果还原默认设置因权限或其他问题失败，还可以手动新建配置文件救急。

以管理员身份打开文件资源管理器，进入 C:\ProgramData\VMware\（如果没有看到，请开启"隐藏的项目"显示）。
右键新建文本文档，重命名为 vmnetdhcp.conf。
用记事本打开，粘贴以下内容并保存：

conf 复制代码

# VMware DHCP Server Configuration File
allow unknown-clients;
default-lease-time 1800;
max-lease-time 7200;

subnet 192.168.220.0 netmask 255.255.255.0 {
    range 192.168.220.128 192.168.220.254;
    option broadcast-address 192.168.220.255;
    option domain-name-servers 192.168.220.2;
    option routers 192.168.220.2;
    default-lease-time 1800;
    max-lease-time 7200;
}

注意事项 ：子网 192.168.220.0 是 VMware 默认值，务必打开"虚拟网络编辑器"检查 VMnet8 的子网地址，确保配置文件中的子网、网关（.2）和广播地址与实际一致，否则 DHCP 服务仍可能启动失败。

保存后，在 services.msc 中启动 DHCP 服务，如果能保持运行，就搞定了。

四、可复用的排查思路

这次排障虽小，却串起了一条清晰的检查链。以后再遇到 VMware NAT 模式下虚拟机拿不到 IP 的情况，你可以按这个顺序快速定位：

虚拟机内部

ifconfig 或 ip addr 看网卡有无 IPv4 地址。

检查 /etc/sysconfig/network-scripts/ifcfg-<网卡名> 确保 ONBOOT=yes、BOOTPROTO=dhcp。

手动 sudo dhclient -v <网卡名> 测试，观察是否收到 DHCPOFFERS。
宿主机服务

services.msc 中确认 VMware DHCP Service 和 VMware NAT Service 都在正常运行。

如果 DHCP 服务启动后停止，立刻去"事件查看器"里找 Service Control Manager 的错误日志。
配置与端口

检查 C:\ProgramData\VMware\vmnetdhcp.conf 是否存在且内容正确。

确认宿主机无其他进程占用 UDP 67/68 端口（netstat -ano | findstr ":67"）。
终极大法

以管理员身份运行 VMware，进入"虚拟网络编辑器"，对 VMnet8 执行"还原默认设置"。

按照这个流程，90% 的此类故障都能迎刃而解。

五、我有话说

这次排障让我再次体会到，很多看似神秘的网络问题，根源往往藏在一个不起眼的文件或服务里。系统里那些安安静静躺着的 .conf 文件，一旦缺位就会让整个依赖链断裂，就像钥匙断了，门就怎么也打不开。

此外，日志永远是最好的朋友。如果一开始就翻事件查看器，可能会省去来回检查虚拟机配置的时间。AI 虽然能帮忙理思路，但最终排查还是要靠那份盯着日志不放过任何"文件找不到"信息的耐心。

时间静止不是简史，我们下期见。