红帽虚拟机无法获取DHCP地址，多半不是系统坏了，而是虚拟网络模式、DHCP服务范围或网卡配置三者没有对齐，按“虚拟化平台→虚拟机网卡→DHCP服务→日志抓包”的顺序排查，多数情况能在十分钟内定位问题。
红帽虚拟机无法获取DHCP地址怎么办？先查虚拟化平台网络模式
红帽虚拟机跑在VMware、VirtualBox、KVM或Hyper-V上，DHCP地址拿不到，第一步不是进系统改配置，而是回到虚拟化平台看网络模式，不同模式对DHCP的来源要求完全不同。
确认虚拟机网络模式是NAT、桥接还是仅主机
- NAT模式：虚拟机通过宿主机的虚拟NAT服务获取IP，DHCP由虚拟化平台的NAT服务提供，如果宿主机虚拟网卡被禁用，或者NAT服务异常，虚拟机就拿不到地址。
- 桥接模式：虚拟机直接连接到物理网络，DHCP请求会广播到物理交换机，这时能否获取地址，取决于物理网络里有没有可用的DHCP服务器，以及交换机是否放行DHCP广播。
- 仅主机模式：只与宿主机通信，DHCP由虚拟化平台的虚拟DHCP服务分配，如果该服务未启动，虚拟机自然没有地址。
业内专家指出,相当一部分“红帽虚拟机无法获取DHCP地址”的案例，根源是用户把网络模式从NAT改成桥接后，没有确认物理网络是否有DHCP服务器。
检查虚拟化平台DHCP服务是否开启
以VMware Workstation为例，点击“编辑”→“虚拟网络编辑器”，选中对应网络，查看“使用本地DHCP服务将IP地址分配给虚拟机”是否勾选，如果是KVM/libvirt，检查default网络的DHCP范围：
virsh net-list --all virsh net-dumpxml default | grep dhcp
如果DHCP范围被耗尽,或者网段与虚拟机网卡不在同一子网，虚拟机也拿不到地址，可以临时扩大地址池，或者重启libvirtd服务：
systemctl restart libvirtd
查看虚拟机网卡是否被识别
进入红帽系统,执行：
ip link show
如果只看到lo,没有ens33、eth0之类的网卡，说明虚拟化平台没把网卡挂给虚拟机，检查虚拟机设置中的“网络适配器”是否已连接，以及是否勾选了“启动时连接”。
桥接模式下红帽虚拟机获取不到IP地址的常见原因
桥接模式最容易被误判,虚拟机看起来和宿主机在同一个局域网，但DHCP请求不一定能到达服务器。
桥接网卡选择错误
VMware的桥接模式可以指定桥接到哪块物理网卡,如果宿主机有有线、无线、虚拟专用网卡多块网卡，桥接目标选错，DHCP请求就会发到一个没有DHCP服务的网络，比如桥接到了虚拟专用网卡，而虚拟专用网络不允许广播，地址自然拿不到。
操作路径：虚拟机设置→网络适配器→桥接模式→配置适配器，勾选当前实际联网的物理网卡。
物理网络限制DHCP广播
企业交换机常开启DHCP Snooping功能，如果连接虚拟机的交换机端口没有配置为信任端口，DHCP请求会被丢弃，这种情况在办公网常见，家庭网络较少，可以换一个端口测试，或者联系网络管理员确认端口配置。
交换机端口安全或MAC过滤
部分交换机开启端口安全,限制每个端口学习的MAC地址数量，虚拟机每次启动可能使用不同MAC地址，触发端口安全策略后，端口被关闭，DHCP请求也发不出去，可以尝试在虚拟机设置中固定MAC地址，或者在交换机上调整端口安全策略。
红帽Linux虚拟机DHCP客户端配置对比：NetworkManager与传统network
红帽企业Linux从RHEL 8开始默认使用NetworkManager管理网络，但很多从CentOS 6/7过来的用户还在用传统network服务，两者对DHCP的处理方式不同，排错时要注意。
传统network服务与NetworkManager的差异
| 对比项 | 传统network | NetworkManager |
|---|---|---|
| 默认启用版本 | RHEL 6及之前 | RHEL 8及之后 |
| 网卡配置文件 | /etc/sysconfig/network-scripts/ifcfg- | 同上，但由NetworkManager接管 |
| DHCP触发方式 | ifup/ifdown | nmcli con up/down |
| 日志位置 | /var/log/messages | journalctl -u NetworkManager |
如果系统同时启用了两个服务,可能互相抢占网卡控制权，导致DHCP请求异常，检查：
systemctl status NetworkManager systemctl status network
建议只保留一个,RHEL 8/9上推荐使用NetworkManager。
手动触发DHCP请求的命令
对于NetworkManager：
nmcli con down "连接名" nmcli con up "连接名"
或者直接：
nmcli device reapply ens33
对于传统network：
ifdown ens33 && ifup ens33
如果手动触发后能拿到地址,但重启后丢失，说明开机自动连接没配置好，检查网卡配置文件里的ONBOOT=yes。
检查网卡配置文件
打开/etc/sysconfig/network-scripts/ifcfg-ens33，确认：
BOOTPROTO=dhcpONBOOT=yesDEVICE=ens33HWADDR与虚拟机网卡MAC一致（可选）
如果BOOTPROTO被写成none或static，DHCP客户端根本不会启动，改完后重启网络服务。
实操：一步步定位DHCP获取失败
第一步：查看网卡状态和IP
ip addr show ens33
如果只有inet6没有inet，说明IPv4地址没拿到。
第二步：检查DHCP客户端进程
ps aux | grep dhclient
传统network使用dhclient,如果进程不存在，尝试手动运行：
dhclient -v ens33
-v会输出详细交互过程，如果一直显示DHCPDISCOVER没有DHCPOFFER，说明请求发出去了但没有服务器响应。
第三步：抓包分析DHCP交互
tcpdump -i ens33 -n port 67 or port 68
观察是否有DHCP Discover发出，是否有Offer返回，如果只有Discover没有Offer，问题在服务器侧或网络路径，如果有Offer但没有Request或Ack，可能是虚拟机防火墙拦截，或者客户端配置异常。
第四步：查看系统日志
journalctl -u NetworkManager --since "10 minutes ago"
或者：
tail -f /var/log/messages
搜索dhcp、dhclient、ens33等关键词，看是否有超时、拒绝、地址冲突的提示。
企业环境与地域服务：北京红帽虚拟机DHCP排错注意事项
企业DHCP服务器与虚拟化平台DHCP的冲突
企业内网通常有独立的DHCP服务器,如果虚拟机使用桥接模式，同时虚拟化平台又开启了自带DHCP服务，可能出现两个DHCP服务器同时响应的情况，客户端拿到哪个地址取决于响应速度，可能导致地址冲突或网关错误，行业共识认为，桥接模式下应关闭虚拟化平台自带DHCP，统一由企业DHCP服务器分配。
委托第三方处理红帽虚拟机DHCP故障的价格参考
如果企业没有专职Linux运维,遇到红帽虚拟机DHCP故障，可以委托第三方服务商，北京地区红帽虚拟机DHCP排错服务，价格通常按次或按工时计费，单次排查费用在几百到上千元不等，具体取决于故障复杂度和是否需要现场支持，如果是长期运维合同，价格会包含在月度服务费中，自行排查时，按本文顺序操作，多数问题不需要额外付费。
Q&A：红帽虚拟机无法获取DHCP地址怎么办？
红帽虚拟机重启后DHCP地址丢失怎么办？
先确认网卡配置文件ONBOOT=yes，再检查NetworkManager连接是否设置为自动连接，执行nmcli con show，查看连接是否处于activated状态，如果每次重启都需要手动nmcli con up，很可能是ONBOOT被改成了no，或者连接被设置为非自动。
红帽虚拟机无法获取DHCP地址，重启网络服务有效吗？
临时有效,但不解决根因，重启网络服务会重新发送DHCP请求，如果只是DHCP租约过期或客户端进程卡死，重启能恢复，但如果虚拟网络模式错误、交换机端口安全、DHCP地址池耗尽，重启后依然拿不到地址，正确做法是抓包确认Discover是否有Offer响应。
红帽虚拟机DHCP获取失败，是否与SELinux有关？
多数情况下无关,SELinux主要控制进程对文件的访问，DHCP客户端写租约文件一般不会被阻止，如果怀疑SELinux，可以临时执行setenforce 0测试，但生产环境不建议长期关闭，更常见的干扰是防火墙规则阻止了DHCP的UDP 67/68端口，检查firewall-cmd --list-all中是否放行了dhcpv6-client或dhcp服务。
红帽虚拟机无法获取DHCP地址,核心排查逻辑就是“先平台后系统，先链路后配置”，把虚拟网络模式、DHCP服务状态、网卡配置文件三个点对齐，绝大多数问题都能自行解决。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/763290.html
