基于iVentoy和Docker打造简易PXE网络装机平台

一直觉得 PXE 网络装机是个有两副面孔的东西：懂配置的人用它批量部署机房很爽，不懂的人光是搭环境就被劝退。传统一套 dnsmasq 做 DHCP Proxy、tftpd 托启动文件、再挂 HTTP/NFS 供镜像的做法，对一台临时组建的装机服务来说维护成本实在太高，换个镜像还要一层层改配置。后来我把 iVentoy 塞进 Docker，整个 PXE 网络装机平台的搭建速度被压缩到了几分钟——把 ISO 丢进目录，客户端开机网启，屏幕上直接出现图形化选单，选中镜像就开始装系统。这篇文章我把自己实际跑通的部署流程、网络规划思路和踩过的坑完整捋一遍，给要批量装机、维护实验室或者机房的朋友做个参考。

1. 为什么我会选择 Docker 来部署 iVentoy

1.1 传统 PXE 方案的痛点

先说说没有 iVentoy 之前，我是怎么被传统 PXE 折腾的。标准流程大概是：dnsmasq 负责 DHCP 和 DHCP Proxy，要在配置里指定 option 66（tftp 服务器地址）和 option 67（启动文件名）；tftpd-hpa 负责提供 bootloader 文件，比如 pxelinux.0、grubx64.efi 这些；真正安装系统的时候还要把 ISO 解压，再用 NFS 或者 HTTP 方式挂载，让安装器能读到 install 源。听起来不复杂，但你只要换一个镜像、换一种架构，就得重新检查 boot 文件路径、修改 DHCP 配置、确认 NFS 挂载参数。最要命的是多台机器同时安装时，任何一个环节出问题，当场就要抓包排查。这类问题单看可能不难，但组合起来维护成本真的很高。

1.2 iVentoy 让网启体验发生了哪些变化

iVentoy 做的事情本质上是把“PXE 服务端”和“引导菜单”这两个东西整合成了一体。它内部集成了 DHCP 服务、TFTP 服务和 HTTP 镜像服务，你不需要手动配置 option 66、67，也不需要准备 pxelinux.0 这些引导文件。最省事的是：ISO 原文件直接丢进去就能用，不用解压、不用挂载。客户端通过网络启动后，会看到一个类似 Ventoy 的图形化菜单，列出服务器上存放的全部 ISO，你选一个就进入了对应系统的安装流程。这种体验几乎把传统 PXE 最劝退的那一层全抹掉了。

1.3 Docker 部署的三个直接好处

iVentoy 本身就提供 Linux 下的可执行压缩包，直接解压也能跑。那我为什么还要坚持用 Docker 跑？三个原因：

• 环境隔离：iVentoy 要监听 67、69 这样的特权端口，还会自带 DHCP 服务，如果宿主机上恰好还有别的网络服务，直接解压运行容易互相干扰。用 Docker 跑，容器独立，出问题直接删掉重建。
• 升级回滚方便：iVentoy 更新比较频繁，解压二进制升级需要手动备份配置和数据目录，而 Docker 只要改一下镜像标签重新起一个容器，旧容器还留着，随时能回滚。
• 迁移成本低：只要挂载目录结构和网络环境保持一致，这个容器迁移到另一台宿主机就是一条 docker run 命令的事，适合临时搭一个装机服务用。

基于这些原因，我最终的方案就是在 Linux 宿主机上安装 Docker，用官方镜像启动 iVentoy 容器，然后把整个使用流程沉淀成了一篇可以直接照抄的笔记。

2. 部署前必须想清楚的网络规划

很多人上来就 docker run，结果客户端一开机网启就卡住，然后跑来问我怎么排查。我看了半天，发现问题往往不在容器本身，而是网络规划一开始就没想清楚。所以这部分必须先讲。

2.1 先搞懂 iVentoy 的 DHCP 工作模式

iVentoy 的 DHCP 相关功能有两种使用姿势：一种是它自己充当完整的 DHCP 服务器，直接从 67 端口广播响应，接管客户端 IP 分配；另一种是 DHCP 代理模式，也就是你现有的路由器或局域网 DHCP 服务器继续负责分配 IP，iVentoy 只去响应 PXE 相关的请求，告诉客户端“引导服务在我这里”。

这个区别特别重要。如果局域网里已经有一个很稳的 DHCP 服务器，你非要把 iVentoy 的独立 DHCP 模式打开，很可能出现两台设备抢着分配 IP 的情况，轻则客户端拿不到地址，重则整个局域网一时半会都上不了网。我实际部署时，如果客户端数量不多且主路由可控，会更倾向于让主路由继续做 DHCP，然后把 iVentoy 放在旁路的 Docker 容器里做引导服务。但也要注意，部分路由器/交换机环境下，DHCP 代理方式可能被网络里的安全策略拦截，那就只能选择一个相对清爽的网段，直接用 iVentoy 当 DHCP 服务器。

简单判断标准：如果你只是搭一个临时装机网络，客户端和宿主机都在一个傻瓜交换机下面，直接用 iVentoy 独立 DHCP 没问题；如果你要把这个服务长期插在公司办公网里，务必先问清楚网管有没有 DHCP Snooping 之类的策略，不然可能直接被断电。

2.2 端口清单与映射注意点

iVentoy 在 Docker 里需要暴露的端口大致有三组：

提示：具体端口号以你拉取的 iVentoy 镜像对应版本文档为准，部署前先去官方页面确认一遍，不同版本可能会调整端口设计。

用 Docker bridge 网络模式时，这些端口都要手动映射。其中 67 和 69 是 UDP 端口，特别是 69，TFTP 的传输模式比较特殊，后面我会专门讲为什么 69 端口在 bridge 模式下容易出问题。简单结论是：在 Linux 宿主机上，我强烈建议直接使用--network host网络模式，让 iVentoy 在宿主机网络栈里原生监听这些端口，少一层 Docker 的 NAT 和代理转发，PXE 稳定性会高很多。

2.3 一条请求链路的全流程理解

部署前最好在脑子里过一遍客户端从开机到进入安装界面的完整链路，后面排查问题会快很多：

客户端网卡 PXE ROM 开机 -> 通过 67/68 端口广播 DHCP 请求 -> iVentoy 响应，并附带引导服务器地址和启动文件名 -> 客户端到 TFTP 69 端口拉取网络引导程序 -> 引导程序运行后，通过 HTTP 从 iVentoy 加载镜像索引和 ISO 文件 -> 显示图形化选单 -> 用户选择 ISO 后进入系统安装器。

理解了这条链路，你就会发现每次排查网启问题本质上就是在问：请求走到了哪一步，哪一步被卡住了。是 DHCP 没响应，还是 TFTP 拿不到文件，还是 HTTP 加载不出菜单？不要再盲目重启容器和客户端了。

3. Docker 部署 iVentoy 实操步骤

3.1 宿主机准备与 Docker 环境检查

部署 iVentoy 的宿主机最好是 Linux，发行版不限。如果你手里只有 Windows 或 macOS，硬要用 Docker Desktop 跑也不是不行，但对于 67/69 这类 UDP 广播敏感场景，Docker Desktop 的网络层跨了虚拟机和宿主转发，稳定性不如甚至可以说远不如 Linux 原生 Docker。装机这事本身讲究省心，别给自己添堵。

Docker 环境如果还没有安装，大部分发行版一条命令就能装好：

curl -fsSL https://get.docker.com | sh systemctl enable --now docker

装完先确认 Docker 守护进程正常运行：

sudo docker version sudo docker ps

如果拉取镜像比较慢，可以先配置 registry mirror（镜像加速地址），不同环境差异较大，建议自行检索当前可用的公共镜像加速配置。这一步不是必须的，但直接影响后续体验。

3.2 使用 docker run 启动

我实际在 Linux 宿主机上最常用的是 host 网络模式，命令很简短：

sudo docker run -d \ --name iventoy \ --restart=always \ --network host \ -v /opt/iventoy/data:/data \ ventoy/iventoy

命令里的几个参数解释下：

• --network host：让容器直接使用宿主机网络，不需要映射端口，DHCP/TFTP 的行为最接近原生运行。
• -v /opt/iventoy/data:/data：把宿主机目录挂载进容器的数据目录，也就是将来放 ISO 和配置的地方。
• --restart=always：宿主机重启后容器自动拉起，适合把装机服务长期跑着。

如果你因为某些原因只能用 bridge 网络模式，例如 Docker 版本或宿主机网络限制不支持 host 模式，那需要显式映射端口：

sudo docker run -d \ --name iventoy \ --restart=always \ -p 26000:26000 \ -p 26001:26001 \ -p 67:67/udp \ -p 69:69/udp \ -v /opt/iventoy/data:/data \ ventoy/iventoy

注意宿主机的防火墙。很多发行版默认开了 firewalld 或 ufw，67/69/26000 这几个端口如果不放行，容器内部服务启动得再好，外部请求也进不来。可以临时用sudo firewall-cmd --add-port=67/udp --permanent这类命令放通，具体看你用的防火墙管理工具。

3.3 使用 Docker Compose 固化配置

如果你的宿主机上管理了多个 Docker 容器，用 Docker Compose 会更清晰。我在专门放装机服务的机器上就写了这样一份docker-compose.yml：

services: iventoy: image: ventoy/iventoy container_name: iventoy restart: always network_mode: host volumes: - /opt/iventoy/data:/data

然后一条sudo docker compose up -d就能拉起。这里还是要强调：network_mode: host只在 Linux 宿主机上行为符合预期，Windows/macOS 的 Docker Desktop 对 host 网络模式的支持非常有限，这也是我反复建议用 Linux 的原因。

3.4 部署后的三连检查

容器启动完不要急着开机网启，先做三件事：

# 1. 确认容器处于 running 状态 sudo docker ps | grep iventoy # 2. 确认 Web 控制台能打开 curl -I http://127.0.0.1:26000/ # 3. 确认关键端口在监听 sudo netstat -lnp | grep -E ':(67|69|26000)'

如果 curl 返回了 HTTP 200，说明管理服务正常。如果 netstat 里 67/69 监听异常，去翻容器日志：

sudo docker logs iventoy

日志里通常能直接看到 DHCP、TFTP、HTTP 服务各自的启动状态，哪个起不来，问题基本就锁定在端口占用和网络模式上了。

4. 第一次网络装机：从控制台到客户端全流程

4.1 Web 控制台和 ISO 管理

部署就绪后，浏览器打开http://宿主机IP:26000，进入 iVentoy 的 Web 控制台。第一次进控制台，界面很简洁，左侧是镜像列表，右侧是客户端装机状态之类的内容。

需要确认宿主机上挂载的/opt/iventoy/data目录里能放 ISO。你把Win10_22H2.iso或者ubuntu-22.04.3-desktop-amd64.iso这类原版镜像直接拷贝进去，回到 Web 控制台，一般刷新一下就能看到它们出现在列表里。iVentoy 不需要你解压或转换镜像，它会自动解析 ISO 里的启动配置。这点对习惯 Windows 原版镜像和 Linux 发行版镜像混用的场景特别友好，我经常一次性扔十几个镜像进去。

不过有一点要提醒：控制台默认可能没有设置访问认证，在很多办公网络环境下这就等于把装机服务裸奔在局域网里。如果当前网络环境不是你独占的临时网线，建议先确认 iVentoy 当前版本是否支持独立的访问密码控制，或者干脆放在一个隔离的 VLAN 里使用，避免被无关人员通过 Web 控制台乱改配置。

4.2 客户端网络启动设置与引导菜单

客户端需要进入 BIOS/UEFI 设置界面，打开网络启动选项，不同品牌主板的快捷键不一样，多数是开机狂按 F12、F8 或 F11 弹出启动菜单，然后选择类似 "PXE" "Network Boot" "UEFI: Realtek/Intel PXE" 这样的选项。如果 BIOS 里把网络栈完全关闭了，首先要在芯片组/集成外设设置里打开 "Network Stack" 之类的开关，否则网卡根本不会发起 PXE 请求。

客户端发起网启后，正常情况下会先经历 DHCP 获取地址，接着屏幕出现 iVentoy 的引导选单。选单里能看到服务器上所有 ISO 镜像，选中目标镜像回车，就开始加载安装器了。这里有个很实用的观察点：如果客户端能进入选单，说明 DHCP、TFTP 和 HTTP 这条链路已经通了，后面装系统阶段出错基本都属于镜像本身或驱动问题。

4.3 Windows 与 Linux 镜像安装的差异处理

Windows 镜像的网启安装流程比较接近日常用 U 盘装系统，会先加载 Windows PE，然后进入安装界面。我常用的原版 Windows ISO 基本都能正常工作，但某些精简版、定制版 ISO 可能由于启动配置不标准，在 iVentoy 选单下没法进入安装器。遇到这种情况，第一选择永远是对调回官方原版镜像，没必要在精简版上耗时间。

Linux 镜像的话，多数主流发行版对网络启动支持很好。需要注意启动方式对架构的影响：BIOS 启动和 UEFI 启动对同一张 ISO 的引导路径可能不同。你在选单里可能会看到同一镜像对应多个启动项，比如 UEFI 模式、Legacy 模式，根据客户端固件类型选对应项。如果客户端是纯 UEFI 且开了 Secure Boot，某些镜像可能需要关闭 Secure Boot 才能正常引导，这个在网启阶段尤其明显。

5. 实际使用中容易踩的五个坑

5.1 客户端拿不到 IP：DHCP 排查链路

这是最容易遇到的坑，现象是客户端开机网启后一直卡在 "Acquiring IP address..." 或者反复尝试 DHCP、最后超时进入本地系统启动。按我经验，最常见的三个原因：

• 网络不通：客户端和宿主机看似在一个交换机上，实际上被二层隔离了。先看客户端能不能 ping 通宿主机，或者宿主机抓包看有没有 DHCP Discover 广播进来。
• DHCP 模式冲突：主路由 DHCP 和 iVentoy 同时响应导致客户端无所适从。可以把 iVentoy 切换到代理模式，或者更直接一点，搭一个独立的小网络只让 iVentoy 分配地址。
• 防火墙拦截了 67/68 端口：很多发行版默认防火墙规则只管常规端口，UDP 67/68 被拦得很不起眼。用tcpdump -n -i 网卡名 udp port 67 or port 68在宿主机上抓包，如果一直只能看到 Discover 而没有 Offer 出去，基本就是防火墙或 iVentoy 服务状态问题。

5.2 UEFI 网启报错：NBP 或 HTTP Boot 问题

客户端在 UEFI 模式下发起网络启动，有时会出现类似 "NBP file not found" 或者直接卡在 "HTTP Boot Failed" 的提示。NBP 全称 Network Boot Program，也就是从 TFTP 服务器下载的引导文件，这个文件找不到，通常不是 iVentoy 的问题，而是 UEFI 固件需要手动指定引导文件路径的场景。少部分主板固件对于厂商远程启动文件名的处理非常死板，需要你在 BIOS 网络启动设置里手动填写 iPXE 或 bootx64.efi 这类文件名。不同 iVentoy 版本的默认文件名可能不一样，你可以去 iVentoy 官方 FAQ 或本地日志里查实际文件名，然后填进主板设置里。

如果报的是 HTTP Boot 失败，先确认这个主板是否支持 UEFI HTTP Boot。很多“网络启动”功能标称支持 UEFI，但实际走的还是 TFTP 拉 NBP 的老路子，HTTP Boot 只是附加项。

5.3 Windows 安装找不到磁盘：VMD/RST 驱动

这个坑我用 iVentoy 装新机器时踩过一次。现象是 Windows 安装器能正常启动，但选磁盘时看不到 NVMe 固态硬盘，设备列表里只有 U 盘或没有磁盘。原因大多是 Intel VMD（Volume Management Device）或 RST 驱动的缺失，这在新款笔记本和部分台式机上尤其常见，它们的磁盘默认挂在 VMD 控制器下，Windows 安装器没有自带对应驱动。

解决办法有两条路：一是进 BIOS 把 VMD 模式改成 AHCI 模式，重新引导后磁盘就能看到，但这会改变硬盘控制器的固件设置，不是所有商务机器都允许；二是把磁盘驱动放进 iVentoy 的插件机制里，让它注入到引导时使用的 PE 环境。具体插件目录结构建议直接参考 iVentoy 官方文档，不同版本差异不小。

5.4 Docker bridge 模式下 TFTP 不稳定：端口映射的坑

如果你用了 bridge 模式而不是 host 模式，网启过程中可能出现一种很诡异的状况：控制台能打开，DHCP 也能响应，但客户端引导文件传输总是到一半就超时，或者时好时坏。问题基本锁定在 Docker 对 69 端口的 UDP 转发机制上。

TFTP 的传输模式和其他常见 UDP 服务不太一样，客户端首先连服务器的 69 端口拿文件，但后续数据包会从服务端一个高位随机端口发回给客户端。Docker bridge 网络的端口映射对这种方式的支持有限，特别是 Docker 的 userland-proxy 机制介入时，TFTP 很容易出现数据包回传丢失，表现就是文件传输卡住。这也是我坚持推荐 host 网络模式的真正原因：少了这一层 NAT 和 proxy 的干扰，TFTP 就不再是玄学问题。如果你受环境限制只能用 bridge，那至少要把 Docker 的 userland-proxy 参数行为了解清楚，并在容器日志里观察 TFTP 请求是否频繁超时。

5.5 并发批量装机时的带宽与镜像加载注意点

批量装机场景对带宽敏感。之前我一次给二十多台机器同时装系统，iVentoy 本身没掉链子，但网络先扛不住了——百兆交换机下，多台机器同时从 HTTP 拉取 ISO 镜像，带宽被瞬间占满，每台机器的安装时间都被拉得很长，其中几台还因为下载过慢导致安装器报错。后来换到千兆交换机，同时装机数量控制在几台到十几台之间，情况就好了很多。另一个经验是，如果镜像源文件比较大、客户端数量又特别多，尽量把 iVentoy 部署在万兆网口或至少千兆网卡的宿主机上，同时确认网卡驱动和 MTU 设置正常。

还有一个特别容易被忽略的细节：批量装完机器后，客户端 BIOS 里的网启优先级往往还排在硬盘之前。等这批机器重新上生产环境时，只要开机偶尔碰一下网络，就可能意外进入 iVentoy 选单，反而把启动流程卡住。装完一批机器后，记得把客户端的启动顺序改回硬盘优先，或者直接把 iVentoy 容器停掉，避免后续误网启。

最后聊聊实际部署中的一点体会

折腾了这么多轮网络装机之后，我的体会是：iVentoy 确实把 PXE 的门槛拉到了很低，但它毕竟还是一个依赖网络基础设施的工具。真正消耗时间的地方不是“把容器跑起来”，而是网络规划、端口放行、固件设置和驱动兼容这些看起来不起眼的环境因素。个人经验是，把网络模式和端口这几件事在部署前想清楚，后面能省一大半排查的力气。另外一个小技巧：给镜像文件命名时把系统版本、架构和用途都标清楚，比如Win11-x64-Designer.iso这种，多人协作装机时控制台选单里的可读性会好很多。网启装机这件事，工具选对了，剩下就是按流程办事，希望这篇文章能帮你少走几步弯路。