Docker部署iVentoy：轻松搭建PXE网络批量装机平台

整天拿着 U 盘一台一台插着装系统，干过的人都懂是什么滋味：先从这台机器把系统装完，再抱着 U 盘走到下一台，中间还要担心 ISO 版本不对、U 盘启动被 BIOS 拦、装机过程中盘符错乱。那如果是一次要处理十几台相同配置的机器呢？这就轮到 PXE 网络装机上场了。可传统 PXE 要自己搭 DHCP、TFTP、文件服务，再手写启动菜单，光是把链路跑通就够劝退一批人。iVentoy 想解决的就是这个尴尬：它把 PXE 服务的复杂度基本抹平，你用 Docker 把它跑起来之后，唯一要做的就是往目录里丢几个 ISO 文件。这篇文章我会从部署、使用、排错三个角度，把基于 Docker 搭建 iVentoy PXE 网络装机平台的完整过程逐步拆开讲，适合机房维护、实验室管理、NAS 玩家，以及所有不想在 PXE 配置上浪费时间的折腾党。

1. iVentoy 是什么，为什么我要用它替代传统 PXE 方案

1.1 PXE 传统链路到底麻烦在哪

PXE（Preboot eXecution Environment，预启动执行环境）本身不复杂，逻辑链路大致是：客户端开机后网卡发 DHCP 广播，DHCP 服务器分给 IP，同时告诉客户端“你的启动文件在哪台服务器上”；客户端再通过 TFTP 下载引导文件，进入一个微型系统；最后通过网络文件服务拉取完整 ISO 或者内核，进入安装流程。

问题在于这套链路里每个环节都是分离的。你最少得有一台 DHCP 服务器、一台 TFTP 服务器、一台 HTTP/NFS 文件服务器，还要手动往启动菜单配置文件里写每一个 ISO 的条目。有些发行版启动参数不同，Windows 和 Linux 的引导文件又不一样，真做起来远不是“装个软件”那么简单。早年做网刻，大家会去找各种 Ghost 网刻工具，专门抽 30 分钟搭配置网络环境也是常有的事。

1.2 iVentoy 把复杂度藏了起来

iVentoy 是 Ventoy 的网络版本。用过 Ventoy 的人应该记得那种爽感：把 ISO 文件复制到 U 盘，启动时自动出现一个多系统选择列表，选谁就启动谁，根本不用格式化、解压、写引导。iVentoy 把同样的逻辑搬到了网络上：你只需把 ISO 放到服务器某个共享目录，iVentoy 会在局域网里自动提供 DHCP/proxyDHCP 应答、TFTP 引导文件和文件下载服务，客户端开机网络引导后，直接看到一个跟 Ventoy 类似的菜单，选择对应 ISO 就能开始安装。

这解决了传统方案的几个痛点：

• 不需要手工维护菜单。新增一个 ISO，控制台稍等几秒自动识别，重新引导客户端就能看到。
• 自动匹配引导方式。同一个 ISO，传统 BIOS 机器和 UEFI 机器都能引导，iVentoy 会根据客户端固件类型选择合适的引导文件。
• 统一文件服务。ISO 传输走 HTTP，传输速度稳定，也方便观察当前谁在下载、下载到了多少。
• 有 Web 控制台。可以实时看到哪些客户端在线，连接状态如何，比在黑乎乎的配置文件和日志里找原因舒服太多。

1.3 我为什么选择用 Docker 来跑它

iVentoy 本身也提供 Linux 安装包，直接装也能用。但我的实践经验是，用 Docker 包装一层更符合现代运维习惯。

首先是可移植性。我在本地测试机调好的镜像版本、挂载路径、端口配置，写到 docker-compose.yml 里后，拿到新的服务器或者 NAS 上直接就能拉起一套一模一样的服务，不用重新解压、配置、排查依赖。

其次是隔离与干净。iVentoy 进程跑在容器里，对宿主机的文件系统侵入很小，升级时换个镜像 tag 再拉起即可，不想要了直接删容器，不用手工清理一堆残留文件。

第三是和 NAS 场景天然契合。现在不少人用 NAS 做家庭/小型办公室的存储中心，NAS 普遍支持 Docker 图形化管理，ISO 文件本身也可以放在 NAS 的磁盘阵列上，数据冗余和容量扩展都比普通服务器省心。

2. 部署前先想清楚的事：端口、镜像与网络模式

2.1 必须了解的端口清单

iVentoy 的端口不算多，但部署前最好先弄明白哪些在用，否则防火墙一挡，客户端会一直卡在 PXE 引导阶段。

实际使用中，如果采用 Docker 的 host 网络模式，端口默认就直接绑定在宿主机上，理论上不用额外做端口映射；但如果宿主机有防火墙或者云安全组策略，别忘了解放 TCP 26000-26002 以及 UDP 67/68/69。不同 iVentoy 小版本对辅助端口的使用略有差异，稳妥做法是这三个 TCP 端口全部放行，反正也不冲突。

2.2 镜像选择：iventoy/iventoy 和 iventoy/iventoy-web 怎么选

iVentoy 官方提供的 Docker 镜像主要有两个：

• iventoy/iventoy：完整服务版，包含后台服务和 Web 控制台，绝大多数场景选这个就对了。
• iventoy/iventoy-web：仅 Web 控制台前端，适合与远程已运行的主服务配合使用，普通单机部署不用碰它。

我之前第一次部署时图新鲜用了 web 版，结果连后端服务都没装，控制台自然连不上后台，后来换回完整版才顺利跑起来。如果你只是需要在局域网里快速搭一套网络装机环境，直接在 Docker Hub 拉iventoy/iventoy:latest，不要犹豫。

另外建议拉取时尽量固定版本 tag，比如iventoy/iventoy:1.0.20，而不是长期依赖 latest，这样后续同一批机器出问题时，版本可复现，排查会容易很多。

2.3 网络模式怎么选：host 优先

这是我在实际部署中感触最深的一点。iVentoy 这类工具的特殊之处在于，PXE 启动依赖 DHCP 广播和 TFTP 这类二层网络协议，如果容器跑在 Docker 默认的 bridge 网络里，外部客户端的启动请求很难正确到达容器内部。

我推荐直接使用 host 网络模式，也就是让容器共享宿主机网络栈。原因有三：

1. PXE 的 DHCP 广播能直接在本网段内被 iVentoy 接收，不用经过 Docker 的 NAT 转换。
2. 端口不冲突时，不需要手动写一堆端口映射，配置更直观。
3. 客户端访问 iVentoy 文件服务时，拿到的地址就是宿主机地址，不会出现“引导文件拿到了，但后续下载 ISO 的地址是个容器内部 IP”这种尴尬。

如果因为某些限制只能用 bridge 模式，那也要把 26000-26002 和 UDP 67/68/69 都映射出来，并且测试客户端能不能正常拿到启动文件。实测下来 bridge 模式在部分网络环境下也能跑通，但一旦遇到跨 VLAN 或 DHCP 冲突，问题定位会非常痛苦，所以对我来说 host 模式是唯一推荐。

2.4 镜像加速与离线导入的备用方案

Docker 拉取镜像官网源速度不理想，是很多人卡在第一步的原因。我通常会先检查当前 Docker 的 registry-mirrors 配置：在/etc/docker/daemon.json里加上可用的镜像源地址，等几秒后执行systemctl restart docker。如果部署环境是离线的内网机器，则更推荐在能联网的机器上先拉取镜像再导出：

docker pull iventoy/iventoy:latest docker save iventoy/iventoy:latest | gzip > iventoy.tar.gz

把 tar.gz 拷贝到目标机器上执行：

gzip -dc iventoy.tar.gz | docker load

这样一个几百 MB 的镜像，用 U 盘或者内网共享传过去，几分钟就能完成离线部署。

3. 三步部署：命令行、Compose 与 NAS 图形界面

3.1 命令行 docker run 一键拉起

在 Linux 服务器上部署，最直接的就是 docker run。先准备好数据目录，然后启动容器：

mkdir -p /opt/iventoy/data docker run -d \ --name iventoy \ --network host \ --restart=always \ -v /opt/iventoy/data:/data \ iventoy/iventoy:latest

这里面的几个参数解释一下：

• -d：后台运行。
• --network host：使用宿主机网络，这是 PXE 服务能正常工作的关键。
• --restart=always：容器异常退出或宿主机重启后自动拉起，装了一半系统服务挂了，那体验确实有点闹心。
• -v /opt/iventoy/data:/data：把容器内的数据目录持久化到宿主机，ISO 文件、配置和日志都放这里。

启动后直接访问http://宿主机IP:26000，看到 iVentoy 控制台说明服务起来了。ISO 存放路径默认是宿主机/opt/iventoy/data/iventoy/iso目录。

3.2 docker-compose 统一管理部署

相比裸 docker run，我更推荐用 Compose 来管理，尤其是同一套环境要部署到多台宿主机时。新建一个docker-compose.yml：

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

然后执行：

docker compose up -d

如果宿主机上的 Docker 版本较旧，Compose 命令可能是docker-compose，注意区分。这么写的好处是，升级时只需要改动镜像版本号，然后执行docker compose up -d，Compose 会自己判断是否需要重建容器；换新服务器时，把 yml 文件和 /opt/iventoy/data 目录一起拷过去，直接拉起来就是一模一样的环境。

3.3 以飞牛 NAS 为例的图形化部署

现在很多 NAS 系统内置了 Docker 管理界面，以飞牛 NAS（fnOS）为例，整体流程非常直观：

1. 打开 NAS 的 Docker 应用，在镜像页面搜索iventoy/iventoy并拉取。
2. 进入容器创建页面，填写容器名称，选择刚才拉取的镜像。
3. 存储空间设置里，把 NAS 上的一个共享文件夹映射到容器的/data目录，今后把 ISO 直接拷到这个共享文件夹即可。
4. 网络模式选择 host。这里特别提醒，如果 NAS 的 Docker 界面默认是 bridge，需要手动切到 host，不然 PXE 广播很难正常到达容器。
5. 设置重启策略为“容器退出时自动重启”，保存并启动容器。

NAS 场景有一个天然好处：ISO 文件放在共享文件夹里，平时可以用电脑通过 SMB/NFS 直接上传，装系统时还能同时让 NAS 上的其他服务正常工作。不过要注意，如果 NAS 开启了多个网口并且做了链路聚合或 VLAN 划分，务必确认 iVentoy 容器绑定的是客户端所在的物理网络。我见过有人把 NAS 插在管理口上，结果客户端始终发现不了启动服务器，最后发现是网口接错。

4. 从客户端到服务器端：PXE 引导的基础链路搭建

4.1 客户端要做哪些准备

服务器端跑通只是第一步，客户端这边如果设置不对，一样白搭。

首先是BIOS/UEFI 设置。开机进固件设置，确认网卡启动（PXE Boot / Network Stack / UEFI Network Boot）是开启状态。现在的商用台式机和笔记本一般默认启用，但部分主板要手动开启“Network Boot”选项。启动时按F12（戴尔/联想常见）或F11、F9等进入一次性启动菜单，选择带 “UEFI” 或 “PXE” 字样的网卡条目。

其次是Secure Boot 问题。如果主板开了 Secure Boot，某些自定义 PXE 引导文件会因为签名验证失败而无法加载。首测阶段建议先关闭 Secure Boot，等整套链路跑通之后，再根据真实启动环境决定要不要临时关掉。特别是 Windows 机器的 Secure Boot 默认和 UEFI 绑定，模板机装完系统后再去动引导模式会是很麻烦的事。

4.2 和现有 DHCP 怎么共存：两种模式

局域网里基本都有路由器的 DHCP 在分发地址，如果这时候 iVentoy 也强行当 DHCP 服务器，很容易出现地址冲突。iVentoy 给了两种思路：

1. iVentoy 自己分配地址：在 Web 控制台里启用 DHCP 功能，设置地址池、掩码、网关和 DNS。这种模式适合“完全隔离的测试环境”，比如一个独立交换机、没有插到公司主网络。现实落地时，办公网络环境通常不建议这么干，会和路由器的 DHCP 打架。
2. proxyDHCP 模式：让现有 DHCP 服务器继续分 IP，iVentoy 只作为“代理 DHCP”响应 PXE 客户端的特殊请求。理解成：客户端的 IP 还是由路由器分，但启动信息由 iVentoy 补充。正常办公网络推荐这种模式，不需要动路由器配置。

如果客户端和 iVentoy 不在同一个二层网络，默认 proxyDHCP 通常收不到广播，这时需要在三层交换机或防火墙上配置 DHCP Relay（dhcp relay / ip helper-address），把启动请求转发到 iVentoy 所在网段。很多“能蹭到网络但死活引导不起来”的诡异问题，最后都能定位到跨 VLAN 这一步。

4.3 首次网络引导的全过程

一切就绪后，客户端从 PXE 启动，屏幕会依次出现：

1. 网卡初始化，显示 “Start PXE over IPv4” 之类的字样。
2. 客户端获取到 IP 地址，同时收到 iVentoy 下发的启动信息。
3. 自动加载引导菜单，几秒后进入一个类似 Ventoy 的图形界面。
4. 选择要安装的 ISO，按回车，开始远程拉取镜像并引导启动。

此时打开 iVentoy 的 Web 控制台，可以看到当前连接的客户端 IP、MAC 地址、正在传输的文件和实时速度。我第一次部署时看到控制台里出现本机 IP，心里就有底了，因为已经证明整个链路“客户端能找到服务器、服务器能下发文件”。

4.4 Windows 和 Linux 安装时要注意的差异

Windows 安装镜像（官方原版 ISO）一般都能被 iVentoy 直接引导，但要注意 UEFI/传统 BIOS 模式匹配。如果一台机器是 UEFI 模式，另一台是传统 BIOS 模式，同用一个 ISO 通常没问题，但部分老 Windows 镜像会挑引导方式。遇到启动后黑屏、报winload.efi错误，优先检查客户端的启动模式和 ISO 是否匹配。

Linux 发行版情况比较杂。主流发行版如 Ubuntu、CentOS、Debian、Rocky 的安装 ISO 基本都能直接引导，但某些精简定制版 ISO 缺少网卡驱动或 initramfs 不完整，在 PXE 拉取阶段就可能失败。我实际遇到过一个内网定制的 CentOS 镜像，本地 U 盘能装，走 PXE 就死机，最后定位到镜像里集成的网卡驱动和 PXE 加载的 kernel 版本不一致。这类问题排查时要多留一个心眼：不是所有 ISO 都适合网络引导。

5. 系统镜像管理、Web 控制台与装机效率提升

5.1 Web 控制台的主要功能

iVentoy 的控制台给我的直观感受是：小而实用。界面不会很花哨，但该有的都有：

• 服务运行状态、版本号和当前服务器 IP 一目了然。
• 已连接的客户端列表，能看到每台机器的连接时间和传输状态。
• ISO 镜像列表，可勾选是否启用某个镜像、删除或重命名文件。
• 服务启停按钮，方便临时维护时不让新的客户端继续接入。

最方便的是它支持实时刷新。我在服务器上往 ISO 目录里复制了一个新镜像，并没有重启容器，大概等几秒控制台就自动出现了这个镜像的条目。这对装机现场非常友好，手上一有新系统包，丢进目录立刻就能用。

5.2 ISO 目录的维护习惯

ISO 放多了以后，随便堆在根目录会很难找。我的习惯是按照用途建子目录：

iso/ ├── Windows/ │ ├── Win11_24H2_x64.iso │ └── Win10_22H2_x64.iso ├── Server/ │ └── WindowsServer2022.iso └── Linux/ ├── Ubuntu_22.04.iso ├── Rocky_9.3.iso └── Debian_12.iso

iVentoy 默认会按照子目录结构展示菜单，分类清晰，现场选镜像也快。命名上建议把版本号和架构写清楚，避免出现两个 “Win10.iso”，最后装错系统的低级失误。修改或删除文件后，控制台会自动更新列表，不用手动触发同步。

5.3 从“装一台”到“装一批”的效率技巧

真正批量装机时，效率提升不只在 PXE 本身，更多在系统安装过程的自动化。iVentoy 解决了“镜像怎么传到每台机器”的问题，接下来还能再往“无人值守安装”方向走：

• Windows 镜像里预置autounattend.xml自动应答文件，安装时自动跳过语言、分区、账号设置。
• Linux 发行版使用 Kickstart 或 cloud-init 配置，实现一键自动分区和基础软件包安装。
• 给每台机器提前规划好主机名规则，装完后通过脚本统一改名称和加域。

老实说，把自动化应答文件做好之后，批量装机和 U 盘装机的效率差距会拉开一个档次：U 盘一台一小时，网络批量大概一台十五分钟，而且人不用守在旁边。

5.4 传输速度与宿主机性能的经验

iVentoy 的 ISO 传输走 HTTP，百兆网络下也能稳定跑，千兆网络拉大型镜像基本就是本地读盘的速度。如果发现启动特别慢，优先排查这几处：

• 宿主机网卡和交换机是否协商到了千兆，很多老机器插着百兆网线但自己没注意。
• ISO 所在磁盘是否有 IO 瓶颈。机械硬盘通读一个大镜像没什么问题，但多台机器同时拉镜像时，随机 IO 会明显上升，有条件就放到 SSD 或者 NAS 的高速存储池。
• 容器挂载目录如果是指向网络附加存储，还要确认 NAS 自身的网卡带宽和 iSCSI/SMB 协议是否够用。

内存没有严格门槛，我跑过的环境 2GB 内存的机器也能正常工作，但长期并发安装建议至少 4GB，避免推流时内存占用过高影响其他服务。

6. 部署和装机过程中的避坑链路记录

6.1 客户端卡在 “No boot filename received”

这是我遇到过最多的一个报错，现象是客户端能拿到 IP，但接着就提示没有引导文件名，然后卡在 PXE 阶段。排查链路可以这样走：

1. 先在 Web 控制台确认 iVentoy 服务正常，并确认它处于允许提供启动服务的状态。
2. 确认客户端和服务器在同一广播域。最简单的测试方法是在客户端所在网络内用另一台电脑访问http://宿主机IP:26000，能访问说明三层可达，不能访问说明跨了 VLAN。
3. 检查 DHCP 应答。如果局域网里路由器 DHCP 和 iVentoy 的 proxyDHCP 同时存在，某些异常情况下客户端只认到了普通 DHCP 应答、没认到 PXE 扩展。这种时候可以在 iVentoy 里手动切换模式，或者临时关掉路由器的 DHCP 做对照试验。
4. 有条件就抓包。在宿主机执行tcpdump -i <网卡名> udp port 67 or port 68 or port 69，看看客户端广播有没有到达、iVentoy 有没有回应。抓包是定位 PXE 类问题最快的手段，比盲目改配置高效得多。

6.2 Web 控制台能开但客户端根本拿不到 IP

这个现象更常见于 bridge 网络模式或者宿主机防火墙配置异常。我的检查顺序是：

1. 查看容器是否真的在运行：docker ps。
2. 确认26000端口能访问，说明容器进程正常。
3. 检查宿主机防火墙是否拦截 UDP 67/68/69。很多 Linux 发行版默认防火墙规则只放行 22 端口和一些常用服务，一定要手动放行 iVentoy 相关端口。
4. 检查 iVentoy 的地址池设置。如果现有网段是192.168.1.0/24，而 iVentoy 地址池错配成192.168.0.0/24，客户端即使收到 DHCP Offer 也大概率不会使用这个地址。
5. 如果网络拓扑里还有其他 DHCP 服务器，先关掉它再测试。办公环境里随便插了一个家用路由器，导致地址池冲突的情况我见过不止一次。

6.3 能引导但 Windows 安装报找不到驱动

正好总结一个容易被误诊的问题。当 ISO 能在菜单里选中，也能进入 Windows 安装程序，但安装过程中提示找不到硬盘驱动或网卡驱动时，其实大概率已经不是 PXE 和 iVentoy 的问题，而是 Windows 镜像自身缺少对应驱动。尤其是 Win7 时代的镜像，在 UEFI 和 NVMe 硬盘环境下非常容易报错。

我的处理办法是：先用微软官方原版镜像跑一遍，如果原版镜像也报同样的错，基本可以排除 iVentoy 传递文件损坏；如果原版正常，那就说明整合镜像有问题，回到镜像制作阶段去补驱动。这样分类，能少走很多弯路。

6.4 Docker 环境起不来的几个常见原因

部署 iVentoy 的第一步，往往不是 iVentoy 本身出问题，而是 Docker 就没起来。Windows 宿主机上最典型的错误是 “Docker Desktop failed to start because virtualization support not detected”。这个提示的意思是：当前 CPU 虚拟化没有开启，或者 Hypervisor 功能没装好。处理方式是：

1. 在任务管理器 -> 性能 -> CPU 里看“虚拟化”状态，如果显示“已禁用”，需要进 BIOS 开启 Intel VT-x 或 AMD-V。
2. Windows 功能里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统（WSL2）”，装完重启。
3. 安装 WSL2 内核更新包，然后把 Docker Desktop 的引擎切到 WSL2 模式。

Linux 宿主机上 Docker 服务本身起不来，通常是 daemon 配置或网络栈问题。先执行systemctl status docker看具体报错，有时候日志会提示存储驱动空间不足，或者残留的容器网络配置导致启动失败。不要一上来就重装 Docker，先看日志，很多问题其实就是 daemon.json 里写错配置导致的。

6.5 镜像拉取过慢或失败怎么办

如果是拉取 iVentoy 镜像这一步卡住，先看 Docker 的 registry-mirrors 配置。编辑/etc/docker/daemon.json，加入可用的镜像源，重启 Docker 后再次拉取。如果放在离线的内网环境，就用前面提到的 docker save / load 方案，提前准备好镜像包。

这里有一个容易被忽略的点：如果在一台机器上拉的镜像是 amd64 架构，而目标机器是 ARM（比如部分 NAS 和开发板），直接导入会运行不起来。拉镜像前先确认目标 CPU 架构，必要时用docker pull --platform linux/arm64拉取对应平台版本。

6.6 升级和数据迁移的注意事项

iVentoy 升级不需要重新部署整套服务，只要把 compose 文件里的镜像 tag 改掉，再docker compose up -d就行。挂载的/data目录不会因容器重建而丢失，ISO、配置和日志都在。

如果要从一台服务器迁移到另一台，最简单的做法是：

tar czf iventoy-data-backup.tar.gz /opt/iventoy/data

新服务器解压同目录后，重新 docker run 一遍，挂载路径保持一致即可。迁移时比较关键的一点是确认新的宿主机 iptables/firewalld 规则放行端口，不然数据目录搬过去了，控制台也起来了，客户端还是连不上。

一点个人经验小结

这套 Docker + iVentoy 的组合，我陆陆续续用了大半年，从最开始给几台测试机装系统，到后来一次性给三十多台机器做批量部署，稳定性一直在线。实际操作中我最大的体会是，Docker 部署只是前菜，真正的关键在把网络链路理清楚：客户端和服务器要在同一广播域、DHCP 模式要选对、防火墙别拦 UDP 端口。把这三件事做对，iVentoy 基本不会给你添乱。

最后分享一个小技巧：首次部署时，建议同时开着 Web 控制台和一个抓包窗口，然后手动触发一台客户端的 PXE 启动。一旦抓包能看到 DHCP Offer 或者 TFTP 请求，你可以确认的问题范围会瞬间缩小，后续的排错也变成纯确认工作。如果你的 NAS 已经在机房里跑着，完全可以让它承担这个角色，ISO 直接放在共享目录里，日常维护几乎零成本。