虚拟机网络启动（PXE Boot）配置的核心在于搭建DHCP、TFTP和启动镜像服务，并确保虚拟机的网络模式与启动顺序正确；若启动失败，绝大多数问题集中在DHCP获取不到地址、TFTP超时或启动文件路径错误这三类原因上。
虚拟机PXE网络启动配置教程：从零搭建无盘引导环境
虚拟机PXE启动配置之所以让不少人头疼，是因为它牵扯到网络基础设施的多个环节，不像光驱安装那样插上就能用，你需要先明白整个流程客户端发送DHCP请求、获取IP和TFTP服务器地址、再从TFTP下载引导文件、最后加载内核和initrd，任何一步断了,表现都是启动失败。
搭建PXE启动所需的服务端组件
在动手之前，先把服务端三个角色理清楚，你可以把DHCP、TFTP、HTTP三合一装在同一个物理机上，也可以分开部署,对虚拟机来说没有区别。
| 服务 | 默认端口 | 作用 | 常见软件 |
|---|---|---|---|
| DHCP | 67/68 | 分配IP地址，广播TFTP服务器位置 | dnsmasq、isc-dhcp-server |
| TFTP | 69 | 传输引导文件（pxelinux.0、vmlinuz） | tftpd-hpa、vsftpd+tftp |
| HTTP/NFS | 80/2049 | 传输系统镜像和安装源 | nginx、httpd |
行业共识认为，dnsmasq是最适合新手和小规模实验室的方案，因为一个配置文件就能同时搞定DHCP和TFTP，减少了排查链路，若用分离部署，则每个服务独立配置,故障排查维度也更多。
虚拟机侧的关键网络设置
这部分最容易出问题，虚拟机启动阶段网卡驱动若未被UEFI固件识别,整个PXE过程就无法开始。
VMware Workstation中，虚拟机设置里勾选“开机时连接”，网络连接选择“桥接模式”而非NAT，NAT模式下DHCP广播能穿透，但TFTP的MTU问题容易导致大文件传输失败，症状就是pxelinux.0下载到一半卡死。
VirtualBox则需要注意网卡类型，选“Intel PRO/1000 MT Desktop”兼容性最佳，半虚拟化网卡（virtio-net）在UEFI PXE阶段可能不被识别，进入虚拟机固件（开机按F2或Esc），在Boot菜单里将“Network Boot”拖到第一项，同时关闭Secure Boot很多发行版的引导文件未签名，Secure Boot会直接拦截。
虚拟机网络启动失败原因：三类高频故障定位
把所有PXE启动失败案例汇总后你会发现，绝大多数逃不出下面三个范畴，按概率排行：DHCP无响应 > TFTP超时 > 引导文件路径错误
。
排查PXE启动报错：从客户端提示逆向定位
先看客户机屏幕上的报错,不同阶段出错代表的问题区间完全不同。
- 第一阶段错误提示“PXE-E51: No DHCP or proxyDHCP offers were received”DHCP响应没到，检查服务端DHCP是否启动、网段是否匹配、虚拟机网卡是否真的连通。
- 第二阶段错误提示“PXE-E32: TFTP open timeout”DHCP成功了，但TFTP文件传不下来，防火墙是否放行UDP 69端口、tftp根目录权限、SELinux状态。
- 第三阶段报“PXE-M0F: Exiting Intel Boot Agent”引导文件下载完成但启动失败，pxelinux.0与配置文件路径不匹配,或者内核与initrd版本不对应导致无法加载。
实际排查中，我在VMware上遇到过一种诡异情况虚拟机从挂起状态恢复后PXE必失败，但冷启动又正常，这是因为挂起恢复时网卡MAC地址会短暂变化，DHCP服务器上的租约记录冲突，后来在DHCP配置中加了ignore unknown-clients并配合VMware的MAC固定功能才解决。
虚拟机启动卡在DHCP阶段的常见原因
客户机界面反复刷“Client MAC ADDR”但始终获取不到IP时，不要急着重启服务,按下面顺序检查：
- 服务端防火墙状态：
systemctl stop firewalld临时关闭测试，能通再放行端口 - DHCP配置文件中subnet和netmask是否与虚拟机的虚拟网络编辑器一致
- 虚拟网络编辑器（VMware）中的DHCP服务是否手动接管
tcpdump -i eth0 port 67 or port 68抓包确认DISCOVER是否到达服务端
若使用VMware Workstation默认的NAT模式，虚拟网卡VMnet8自带DHCP服务会与你自建的DHCP服务冲突，解决办法是打开“虚拟网络编辑器”，选中VMnet8，取消勾选“使用本地DHCP服务将IP地址分配给虚拟机”，改为仅保留NAT设置,把IP分配交给你的PXE服务器。
引导镜像加载失败的深度排查
当pxelinux.0下载成功但菜单出来后选择安装却报错“Failed to mount HTTP server”，问题出在安装源而非引导本身,RHEL系和Debian系的引导参数写法差异较大。
以RHEL 9.4为例，PXE菜单中需要完整指定inst.repo参数：
label linux
kernel RHEL94/vmlinuz
append initrd=RHEL94/initrd.img inst.repo=http://192.168.1.10/RHEL94/ inst.ks=http://192.168.1.10/ks.cfg quiet若内核启动到一半提示“
dracut-initqueue timeout”，优先检查HTTP服务是否可达、防火墙是否放行80端口，早期遇到过排查半天才发现是nginx配置的root路径忘了加/RHEL94这个子目录,404直接导致安装源失效。
虚拟机PXE启动效率优化建议
面向批量化部署场景，PXE启动的瓶颈往往不在网络而在镜像处理上，对数百台虚拟机同时网络安装的场景,可以从两个维度优化：
- HTTP服务开启sendfile和tcp_nopush，提升大文件传输吞吐
- 将squashfs镜像压缩级别从xz改为zstd，压缩率略降但解压速度提升明显
- 在vSphere环境中，批量PXE部署数十台虚拟机时，将安装镜像放到独立的VMFS数据存储上，避免与生产虚拟机争抢存储I/O
配置完成后，从按下电源键到进入安装界面，物理机与虚拟机的差异在50%以内，PXE网络安装虽然前期配置繁琐,但在生命周期管理和自动化运维中的效率优势是光盘和U盘无法比拟的。
虚拟机PXE安装系统网络引导失败怎么解决实用排查清单
从实机操作经验来看，将上述排查路径整理为一张可操作清单，比理解原理更能直接解决问题,以下顺序是经过多次验证的排查优先级：
- 确认客户机网卡已连接在vSphere或Workstation的虚拟机设置中，确认“设备状态”里的“已连接”和“开机时连接”都处于勾选状态
- 关闭安全启动等窄处理方式是在虚拟机固件设置中将Secure Boot设为Disabled；部分平台还需同时将Boot Mode从UEFI切换为Legacy BIOS
- 验证DHCP服务正常服务端执行
systemctl status dhcpd查看活动状态，再执行journalctl -u dhcpd -n 50查看最近日志有无地址池耗尽记录 - 测试TFTP连通性在客户端机器（或宿主机）执行
tftp <服务器IP> -c get pxelinux.0，能下载说明基本通路正常 - 检查UDP端口占用UDP 69端口被占用会导致TFTP进程启动失败，
ss -ulnp | grep :69查看占用情况
这套流程走下来，约八成启动问题能在十分钟内定位，剩余两成涉及服务器负载均衡、VLAN间路由策略等复杂环境因素,需要结合抓包分析解决。
虚拟机网络startup失败后续处理方案
虚拟机PXE启动失败后，切忌反复重启尝试这不会解决配置层面的bug，但会在服务端日志中刷大量错误记录,干扰后续定位。
如果PX
E始终弄不好，有一个临时替代方案：准备一个最小体积的Linux live CD镜像挂载为虚拟机光驱，从光盘启动后再手动挂载NFS上的镜像进行安装，虽然绕了一圈，但能够把PXE的问题与镜像本身的问题隔离很多情况下是镜像配置而非PXE服务有问题。
另一类特殊情况是虚拟化平台自带的PXE支持差异，VMware ESXi主机上的虚拟机，网络启动配置在虚拟机选项的“引导选项”里勾选“尝试网络引导”，而KVM/libvirt环境则需在虚拟机XML中配置：
<os> <type arch='x86_64' machine='pc-q35-7.2'>hvm</type> <boot dev='network'/> </os>
修改XML后需virsh define重新加载配置才会生效，Hyper-V平台则在虚拟机固件设置中直接把“从网络适配器启动”拖到首位。
虚拟机PXE网络引导问答
虚拟机UEFI模式下的PXE启动需要额外注意什么？
UEFI模式与BIOS模式最大的区别是启动文件和路径完全不同，UEFI PXE使用的是grubx64.efi或shimx64.efi，而不是BIOS下的pxelinux.0；TFTP目录结构也变成/EFI/BOOT/这样的路径，若UEFI模式下PXE启动失败，第一反应应检查TFTP目录中是否存在EFI目录结构，而不是BIOS引导文件，部分主板厂商还区分ipv4和ipv6的PXE入口,注意在固件设置中选对网络栈类型。
虚拟机PXE启动时屏幕显示红色报错“Network boot failed”直接退出，如何处理？
这个报错表明PXE客户端已尝试向网络发起引导但未能找到任何可用的启动服务器，首先查看虚拟机网卡连接的端口组是否已配置正确的VLAN，尤其在使用物理交换机端口组的vSphere环境中，VLAN ID不匹配会导致DHCP报文根本无法到达服务器，其次检查服务端DHCP地址池范围，确保地址池未被其他租约占满,若地址池已满可临时扩大范围或缩短租约时间后再试。
在VirtualBox虚拟机中为何无法使用PXE网络启动？
VirtualBox默认将网卡类型设为“Intel PRO/1000 MT Desktop”（E1000），该型号在UEFI PXE环境下存在兼容性问题，将网卡类型更换为“virtio-net”可解决多数问题，若使用的是半虚拟化网卡且仍无法启动，可考虑更新VirtualBox版本早期版本对UEFI PXE支持不完整，新版本已完善了这部分功能，检查BIOS设置中是否开启“Network Boot”选项，部分VirtualBox版本默认关闭该选项，需在“系统”->“主板”->“启动顺序”中勾选“网络”并移至首位。