虚拟机DHCP租约到期后无法获取IP？先做这三步检查
当虚拟机在DHCP租约到期后突然无法获取IP，最直接的解决路径是：先确认虚拟网卡是否被宿主机或虚拟化平台误断开，然后手动释放并续租IP，最后检查DHCP地址池是否枯竭或网段冲突。 大多数情况下，问题出在虚拟交换机端口组配置或防火墙策略上,而不是虚拟机系统本身。
为什么租约到期会导致虚拟机“失联”？
DHCP租约不是永久的，默认通常是24小时，租约过半时客户端会尝试续租，如果在租约到期前没有成功续约，IP地址会被回收，虚拟机环境比物理机更敏感，因为虚拟网卡的状态变化、快照回滚、迁移操作都可能让租约状态异常，常见场景是：你前一天还能连上虚拟机，第二天开机发现IP变成了169.254.x.x（APIPA自动私有地址），或者干脆显示“未识别的网络”。
行业共识认为，超过半数的虚拟机IP异常问题，根源不在DHCP服务器，而在于虚拟化层的网络适配器设置，尤其是VMware ESXi和Proxmox VE这类平台，如果端口组的安全策略里启用了“MAC地址欺骗”限制，但虚拟机又自定义了MAC地址,租约续租时就会被交换机直接丢弃。
虚拟机DHCP获取不到IP怎么办？按顺序排查虚拟网络层
先别急着进系统敲命令，虚拟化平台的网络状态是第一步，你可以在vCenter或Web管理界面里，查看该虚拟机的“网络适配器”是否显示“已连接”，很多时候，迁移或快照恢复会把网卡连接状态重置为“未连接”,勾选上就恢复了。
如果网卡状态正常，接着看虚拟交换机的端口组配置，以VMware标准交换机为例，进入“主机→网络→虚拟交换机→端口组”，检查VLAN ID是否和物理交换机对应，VLAN不匹配会导致DHCP发现报文（DHCP Discover）广播不出去，客户端自然收不到OFFER，Proxmox用户则要看Linux Bridge（vmbr）是否绑定了正确的物理网卡，/etc/network/interfaces里如果bridge_ports写错,虚拟机就像插了根没接路由器的网线。
手动续租命令：Windows、Linux真实执行步骤
虚拟网络没问题,那就在虚拟机系统里手动强制续租。
Windows Server/桌面系统：
- 以管理员身份打开CMD或PowerShell。
- 执行
ipconfig /release释放当前租约，执行后IP会变成0.0.0.0。 - 执行
ipconfig /renew重新请求DHCP租约。 - 观察输出，如果卡在“无法联系 DHCP 服务器”超过十几秒，说明广播没到达DHCP，可以用
ipconfig /all确认网卡是否启用了DHCP。
Linux（Ubuntu/Debian/CentOS）：
- 对于使用Netplan的Ubuntu 20.04+，执行
sudo netplan apply重新应用网络配置。 - 传统sysconfig的CentOS，执行
sudo systemctl restart network或sudo dhclient -r eth0 && sudo dhclient eth0（网卡名替换为实际接口）。 - 如果虚拟机里装了cloud-init，可能还会自动重置网络配置，这时要检查
/var/log/cloud-init.log是否有报错。
排查DHCP服务器端地址池和租约记录
客户端没问题，就去看DHCP服务器，无论你用Windows Server的DHCP角色、Linux的ISC DHCP还是路由器内置的DHCP,都关注三件事：
- 地址池剩余数量：如果地址池只有50个地址，但虚拟机数量加上物理手机、打印机超过50个，新设备自然拿不到，统计显示,小型办公室最常遇到的就是员工手机把地址池挤爆。
- 租约时长设置：如果租期设的特别长（比如7天），虚拟机频繁休眠唤醒可能导致续租请求被拒绝，可以适当缩短到2小时测试,但生产环境不建议改动过于频繁。
- MAC地址过滤：有些管理员会在DHCP里做“仅允许已知MAC地址分配”，新克隆的虚拟机MAC地址变了,就会被静默拒绝。
虚拟机重启后IP变了和租约到期有什么区别？
这是两个常见问题，但很多人混淆，虚拟机重启后IP变了，通常是DHCP服务器分配了不同地址（原因可能是原租约被释放、或地址池顺序调整），而租约到期无法获取IP，是彻底拿不到地址，如果你只想让虚拟机IP固定，不要让虚拟机的IP地址总是变化，用DHCP保留（Reservation）是最稳妥方案。
在DHCP服务器上，根据虚拟机网卡MAC地址创建保留，把固定IP绑定好，注意：虚拟机克隆后必须重新生成MAC地址，否则会和源虚拟机冲突，在VMware里克隆时选择“生成新的MAC地址”，在KVM/QEMU里编辑XML配置时移除
<mac>段让libvirt自动生成。
公网IP和内网IP同时失效的异常场景
有些云虚拟机（比如简米云、酷番云）用的是静态DHCP保留，租约到期后如果云平台管控组件没同步，可能出现内网IP失联，但公网IP（EIP）依然能通，这种情况别折腾系统，直接到云控制台“重启实例”或“停止-启动”一次，让云平台重新注入网络配置，据统计，云厂商工单中心有相当一部分“无法连接服务器”的问题,就是通过强制重启解决的。
排查宿主机的DHCP中继和物理网络环路
如果你的虚拟化环境跨越多个物理机，并且DHCP服务器不在本网段，就要检查DHCP中继（ip helper-address），很多人在物理交换机上配了中继，但虚拟机所在的VLAN ID在核心交换机上不存在，或者中继地址指向了错误的内网DHCP服务器IP,就会导致DISCOVER包到达不了DHCP服务器。
另一个被忽视的问题：物理局域网里有多个DHCP服务器（比如无线路由器也开着DHCP），它们分配的网段互相冲突，虚拟机可能从错误的DHCP服务器拿到了不同网段的IP，导致网关不通，你可以抓包验证：在虚拟机上用Wireshark过滤bootp，看DHCP Offer是从哪个IP返回的，如果返回的IP不是公司正式的DHCP服务器地址,赶紧关掉无线路由器的DHCP功能。
防火墙和ARP表导致租约续期被拒
部分企业的终端安全软件（比如EDR）会拦截虚拟机的DHCP广播，因为它们把广播包误判为扫描行为，治本方法是在安全软件里放行虚拟机的DHCP客户端进程（如Windows的svchost.exe或dhclient），如果虚拟机长时间休眠重连，物理交换机上的ARP表项老化，也可能导致DHCP服务器应答回不来，这时在物理交换机对应端口上执行clear arp或重启虚拟化主机的网卡,可以快速恢复。
一个真实的排查案例：Proxmox全家桶环境
有位朋友跑了个Proxmox VE集群，所有虚拟机配置的是同一个Linux Bridge网段，DHCP由OpenWrt软路由分配，某天发现两台Windows Server虚拟机在租约到期后无法获取IP，但Linux虚拟机正常，排查时发现，Windows虚拟机的网卡驱动版本过旧，而Proxmox升级内核后，virtio-net驱动兼容性出了问题网卡在“已连接”状态但收不到任何广播。
解决办法很简单：在Proxmox的硬件配置里，把网卡类型从VirtIO（半虚拟化）改成E1000e模拟网卡，重启虚拟机后立即恢复DHCP，之后更新Windows内的virtio驱动并切回VirtIO网卡，这类驱动兼容性问题在KVM架构下比VMware更常见，如果你用PVE，遇到Windows虚拟机网络异常，优先检查virtio-net版本。
从根源防止租约问题反复出现
排查解决后,建议做三件防患于未然的事：
- 在DHCP服务器上针对服务器类虚拟机创建无限期或长期租约（比如30天）,避免频繁续租。
- 开启DHCP服务器的日志功能，Windows Server的DHCP控制台里可以启用“审核记录”，Linux的dhcpd可以配置log facility，这样以后再出问题,直接看日志就知道是哪个环节断的。
- 定期检查物理交换机端口状态，有些网管型交换机开启了STP（生成树协议），虚拟机网卡快速多次切换会导致端口进入阻塞状态（通常30-50秒），表现为间歇性无法获取IP，如果确认没有环路,可以在连接虚拟化主机的端口上启用PortFast或edge模式。
常见问题速查（Q&A）
Q：虚拟机DHCP获取不到IP，但能ping通同网段其他虚拟机，是什么原因？
A：能Ping通说明第二层网络通，但你可能拿的是APIPA地址（169.254.x.x）Windows系统在DHCP失败后自分配地址，同网段的虚拟机如果也自动分配到了类似地址，确实能互相通信，但网关不通，用ipconfig /all确认IP段，如果是169.254开头,按上述方法手动续租或检查DHCP中继。
Q：KVM虚拟机重启后DHCP租约还在，但就是连不上，怎么快速恢复？
A：先检查宿主机上的虚拟网卡是否还挂着，用virsh domiflist <虚拟机名>查看接口状态，如果接口显示正常，执行virsh reboot <虚拟机名>强制重启客户机网络，仍不行就在宿主机上执行ip link set vnet0 down && ip link set vnet0 up（替换为实际接口名），重新触发网卡链路事件,DHCP客户端会自动重新发送发现包。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/611831.html
