虚拟机验证DHCP配置不成功，九成是虚拟网络模式选错或者DHCP服务没启动，先检查VMware的NAT模式与Windows的DHCP Client服务，再谈其他原因。
排查虚拟机dhcp获取不到ip时先看网络模式
很多朋友在虚拟机里折腾DHCP，半天没反应，第一反应是改配置文件，其实方向错了。虚拟机能否从DHCP服务器拿到地址，首先取决于虚拟网卡连接到了哪张虚拟交换机上，VMware Workstation和VirtualBox的默认网络模式不一样,行为差异巨大。
VMware下vmware dhcp分配失败的原因
VMware Workstation默认有三种网络模式：桥接模式、NAT模式、仅主机模式，如果你选用的是桥接模式，虚拟网卡直接暴露在物理局域网中，这时候DHCP请求会发给真实的路由器或公司内网的DHCP服务器，如果物理路由器关闭了DHCP功能，或者网段不匹配，虚拟机自然拿不到地址，行业共识认为，桥接模式下的DHCP分配失败，多数情况下是物理网络环境不允许,而不是虚拟机配置本身出了问题。
NAT模式则不同，VMware会虚拟出一个VMnet8网卡，虚拟机通过它访问外网，DHCP服务由VMware自带的虚拟DHCP服务器提供，如果你在NAT模式下验证DHCP不成功，优先检查虚拟网络编辑器里的DHCP设置是否勾选了“启用DHCP”，这个选项藏得有点深，路径是：菜单栏“编辑” -> “虚拟网络编辑器” -> 选中VMnet8（NAT模式） -> 查看下方“DHCP设置”，默认起始地址池一般是168.x.128到168.x.254，如果地址池被改成了不连续的子网段,分配就会失败。
VirtualBox中virtualbox dhcp不生效的常见误区
VirtualBox的默认网络模式是NAT，它内置了一个非常精简的DHCP服务器，地址段通常是0.2.15到0.2.24，租约时间较短，如果你在VirtualBox里把网卡改成了“桥接网卡”却忘了关闭VirtualBox自带的DHCP服务，就会出现地址冲突或获取超时，另一个高频失误是：用户手动指定了IP，却忘了关掉“启用DHCP”的接口选项,导致系统内部网络配置和虚拟网卡状态互相打架。
具体操作路径：VirtualBox管理器 -> 选中虚拟机 -> “设置” -> “网络” -> 选择“NAT”或“桥接网卡” -> 点开“高级” -> 确认“接入网线”勾选，不少用户会发现，重装VirtualBox后，默认网卡是“未指定”，这种情况下操作系统根本看不到网卡接口，
ipconfig输入后只显示回环地址。
检查系统内部服务与dhcp client状态
网络模式选对了，但虚拟机还是拿不到IP，这时候要把目光从虚拟机外部转回操作系统内部，无论是Linux还是Windows，都内置了一个DHCP客户端服务，这个服务一旦罢工,配置文件写得再完美也是白搭。
微软Windows虚拟机验证DHCP命令操作
在Windows虚拟机里，验证DHCP是否生效的标准流程是两步，第一步，打开命令提示符，输入ipconfig /release释放当前地址，紧接着输入ipconfig /renew重新申请，如果屏幕上提示“无法联系您的DHCP服务器”，说明数据包根本没发出去或者没收到回应，此时顺手敲一下ipconfig /all，重点看“DHCP已启用”那一行是不是“是”。
如果你的Windows虚拟机出现过快照回滚，DHCP Client服务极有可能处于停止状态，按下Win + R键，输入services.msc回车，在服务列表里找到“DHCP Client”，双击查看启动类型是否为“自动”，服务状态是否为“正在运行”，据统计，相当一部分虚拟机dhcp获取不到ip的案例,就是因为在优化系统时误关了此服务。
Linux虚拟机查看DHCP租约文件
Linux系统相对直白，CentOS和Ubuntu查询租约文件的命令不一样，CentOS看/var/lib/dhclient/dhclient.lease，Ubuntu看/var/lib/NetworkManager/dhclient-.conf，打开租约文件，如果里面有dhcp-server-identifier和renew时间记录，说明DHCP握手已经成功了，剩下的问题大概率出在路由，没有租约记录的话，手动执行dhclient -v强制获取，观察输出内容里的DHCPDISCOVER和DHCPOFFER报文，如果只有DHCPDISCOVER没有后续报文，那就是服务器方向的问题；如果收到了OFFER却收不到ACK,通常是指定IP冲突。
虚拟机静态ip和dhcp对比决定配置路径
排查了上述所有环节还是不行，就得审视你到底该用静态IP还是DHCP，很多工程师在虚拟机里既想保留DHCP的即插即用，又想固定地址，于是手动配置了网卡IP后又让DHCP服务继续运行,这在大部分真实网络环境中会引发地址池冲突。
场景一：虚拟机主要用于本地开发测试，不涉及外部设备访问，这种情况下，虚拟机和物理机做静态ip和dhcp对比的结论往往更倾向于静态IP，可以直接在虚拟网络编辑器里关闭DHCP，手动给虚拟机分配一个和虚拟网卡同网段的地址，比如VMnet8的NAT网段是168.88.0，宿主机虚拟网卡地址是168.88.1，虚拟机网卡就设为168.88.128，网关指向168.88.2（这是VMware NAT网关的默认IP）。
场景二：虚拟机需要经常迁移快照，或者创建克隆机，这时候用DHCP更省心，否则每个克隆都得改一遍IP，但要注意：VMware的DHCP分配地址跟MAC地址绑定，如果克隆后MAC地址变了，地址也会变，如果你想固定，就得在虚拟机设置里选择“高级” -> “MAC地址” -> 点击“生成”,然后用这个新MAC在虚拟网络编辑器的DHCP租约里添加静态绑定。
场景三：公司办公用的域名检索环境，这类局域网内通常有域控，域控内置DHCP授权，如果虚拟机的DHCP请求响应时间过长，业内专家指出可以先用nslookup确认DNS服务器连通性，因为多数DHCP服务器在分配IP的同时会下发DNS地址,DNS配置异常会让人误判整个DHCP流程失败。
验证虚拟机DHCP失败的进阶排查法
如果以上常规手段都试过，问题还顽固存在，不妨从底层链路和防火墙入手,这些细节很容易被忽略。
虚拟网卡防火墙拦截DHCP报文
不少Windows宿主机自带的安全软件会拦截虚拟网卡上的UDP 67和68端口流量，DHCP协议基于UDP，客户端向255.255.255发送广播，如果宿主机防火墙屏蔽了虚拟网卡的广播包回应，虚拟机收到的永远是超时，验证方法很简单：临时关闭宿主机的防火墙和安全软件，再在虚拟机里执行ipconfig /renew，如果地址瞬间拿到，说明防火墙规则要放行VMnet8和VMnet1网卡的DHCP流量。
快照回滚导致的dhcp服务异常
虚拟机的好处是快照，坏处也是快照，当你回滚到某个早期快照时，虚拟网卡的配置文件（VMware中的
.vmx文件或VirtualBox的.vbox文件）和系统内部的网络服务状态可能不一致，典型症状是：启动虚拟机后能看到网卡，但网络连接显示“未识别的网络”，这时候直接删除虚拟网络编辑器里的所有虚拟网卡，重新按照默认参数添加一遍,比手动改配置更快。
日志文件确认失败原因
最后一步是看日志，Windows虚拟机在“事件查看器” -> “系统”日志中，过滤Dhcp-Client来源，能看到事件ID 1001或事件ID 50036，信息里通常会写明“无法获取DHCP地址”以及“操作超时”等字样，VMware Workstation自身的日志在%TEMP%vmware-vmnet-.log，打开后搜索DHCP关键词，能直接看到是请求没发出还是回应被丢弃，这套组合拳打下来,虚拟机验证DHCP配置不成功的问题基本能定位到具体环节。
虚拟机dhcp配置不成功相关问题解答
问：为什么虚拟机网卡显示“正在识别”且IP地址是169.254.x.x开头？
答：254.x.x是APIPA自动专用地址，意味着DHCP客户端发出了多次请求但没人应答，优先确认虚拟网络编辑器里的DHCP服务是否启动，其次检查虚拟网卡是否连接在正确的虚拟交换机上，如果使用NAT模式，尝试重置VMnet8网卡后再启动虚拟机。
问：公司内网环境如何让虚拟机从物理DHCP服务器获取IP？
答：将虚拟机网络模式设为“桥接模式”，并确保桥接到实际接入公司网络的物理网卡（通常是有线网卡，而不是WiFi），部分公司交换机开启了端口隔离或DHCP Snooping，虚拟机通过桥接发送的DHCP请求可能被丢弃,此时需要联系IT部门开通对应端口的DHCP权限。
问：VMware克隆虚拟机后DHCP获取到相同IP导致冲突怎么办？
答：克隆后的虚拟机会沿用母机的MAC地址，在VMware中右键虚拟机 -> “设置” -> “网络适配器” -> “高级”，点击“生成”新的MAC地址，确认MAC变更后进入系统，Linux下删除/etc/udev/rules.d/70-persistent-net.rules重启网络服务，Windows下在设备管理器中卸载网卡再扫描硬件改动,然后重新执行DHCP获取流程。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/653882.html
