Docker部署iVentoy，零配置搭建PXE网络批量装机平台

折腾过多台机器装系统的人都有体会，最怕的不是装一台，而是同一批机器要一台一台插U盘、选镜像、按安装向导。尤其赶上二三十台设备同时交付，整套流程下来加班跑不掉。后来我在一个项目里被逼着换思路，开始看 PXE 网络装机方案，折腾一圈之后锁定了 iVentoy，并且用 Docker 把它部署到了家里的 NAS 上。今天就把这套“Docker + iVentoy 搭建 PXE 网络装机平台”的完整过程分享出来，从原理、规划到命令、排障，一次讲透。

iVentoy 本质上是一个网络版启动盘工具，它把传统 PXE 装机里最折腾的 DHCP、TFTP、启动菜单、ISO 加载全部打包成一个开箱即用的服务。你用浏览器打开它的管理界面，把 ISO 镜像丢进去，同一局域网的机器开机从网卡启动，就能直接看到镜像列表并选择安装。整个过程不再需要任何物理U盘，也基本不用手写 Linux 下那堆 PXE 配置。我推荐所有机房维护、批量交付、实验室设备管理，甚至只是想在局域网里折腾系统安装的朋友，都试试这套方案。

1. iVentoy 是什么，为什么说它是 PXE 批量装机的最优解

1.1 从 U 盘到 PXE：批量装机的效率变化

先聊聊装机这件事的历史。早年装机基本靠光驱，后来是 U 盘量产工具，再后来 Ventoy 这类“把 ISO 丢进 U 盘就能引导”的工具成了主流。Ventoy 的思路很简单：U 盘做一个特殊分区，里面放任意数量的 ISO，开机后自动弹出菜单让你选。这个方案单机用非常舒服，但一到批量场景就露馅了——你手里有多少台机器，就得插多少次 U 盘。

PXE 的出现就是为了解决“不给每台机器插 U 盘”的问题。它的全称是 Preboot eXecution Environment，简单说就是让网卡在开机阶段参与启动流程：机器开机后，网卡向网络里发一个 DHCP 广播请求，DHCP 服务器除了分配 IP，还会告诉客户端“你去 TFTP 服务器下载这个启动文件”，客户端下载启动文件后，再由启动文件引导后续的安装环境。理论上只要网络里有这么一台服务器，几十台机器可以同时通过网络装系统，装完一台重启，它又会回到网络启动环境，继续装下一台。

但传统 PXE 方案的配置门槛一直很高。你要自己装 DHCP 服务器，在配置文件里写 subnet、range、next-server、filename；要自己配 TFTP 服务，把 bootloader、内核、initrd 都按指定目录结构放好；还要写 PXELINUX 菜单，不同系统配不同的内核参数。对不熟悉这套链路的人来说，光是把一个 CentOS 镜像成功 PXE 引导起来，就可能折腾一整天。这也是为什么很多人宁愿继续插 U 盘。

1.2 iVentoy 与传统 PXE 的配置差距

iVentoy 解决的正是“让 PXE 从复杂配置变成零配置”的问题。它是 Ventoy 作者开发的一个独立项目，思路是把自己伪装成一个完整的 PXE 服务端，但把所有复杂度都封装在底层。你部署好之后，剩下的操作基本就是：打开 Web 界面，把 ISO 镜像放到共享目录或直接上传，刷新列表，完事。

它和传统 PXE 方案的核心差异在于：

• 传统方案要分别管理 DHCP、TFTP、HTTP/NFS、菜单文件，iVentoy 把这四层全部内置，一个服务全搞定。
• 传统方案新增一个 ISO 要手工调菜单，iVentoy 是自动扫描镜像目录，目录里新增文件，Web 界面立刻能看到。
• 传统方案对不同 Linux 发行版、Windows 版本经常要单独调内核启动参数，iVentoy 沿用 Ventoy 对 ISO 的良好兼容，绝大多数镜像放进去就能引导。
• 传统方案出了问题你得从 dhcpd、tftp、pxelinux 三个维度同时排查，iVentoy 有统一的 Web 控制台和日志界面。

我之前也搭过一套完整的手工 PXE 环境，能跑，但维护成本确实高。后来换成 iVentoy，最大的感受是“它能让我把精力放在装机本身，而不是折腾引导链路”。

1.3 Docker 部署的优势与场景适配

iVentoy 官方提供了 Linux、Windows 多种部署方式，但我个人最推荐 Docker。原因很现实：

第一，Docker 镜像把依赖全部打包好了，不需要你手动安装一堆运行库，也不存在“在我机器上能跑、在你机器上跑不起来”的问题。第二，iVentoy 的配置和镜像都放在数据卷里，容器本身可以随时删除重建，升级版本时数据不会丢。第三，家里有群晖、威联通、飞牛 NAS 这类设备的用户非常多，NAS 上通常自带 Docker 环境，等于一台小主机就能把装机服务器给跑了，不需要额外准备专门的物理机。

我自己就是把 iVentoy 跑在一台飞牛 NAS 的 Docker 里，平时它干 NAS 的活，需要装系统时把镜像丢进共享目录，同一个局域网内的电脑开机网络启动就能装系统。这种“复用现有设备”的思路，对于不想为装机单独买服务器的人来说特别实用。

2. 部署前规划：网络、端口、硬件这些关键点先想清楚

2.1 服务器硬件与系统要求

很多人一听到“PXE 服务器”就觉得要一台高配机器，其实完全不是。iVentoy 本身对 CPU 和内存的要求非常低，官方甚至表示很低的配置就能跑起来。按我的实测，512MB 内存、单核 CPU 就能稳定运行。真正的硬件瓶颈在存储和网络：

镜像会全部放在服务器磁盘上，一个 Windows 11 的 ISO 大概 5~6GB，一个 Ubuntu Server ISO 大概是 2GB 左右。如果你打算放十来个常用镜像，建议预留至少 80GB 存储空间。读取镜像的磁盘 I/O 也很重要，传统机械硬盘在单机安装时问题不大，但如果同时有七八台机器通过网络拉镜像，机械硬盘可能会成为瓶颈。有条件的话，把镜像目录放在 SSD 上，并发装机会稳很多。

网络方面，强烈建议服务器使用有线网络连接，千兆是底线。如果你的客户端数量很大或者镜像体积动辄几 GB，可以考虑万兆网卡。无线网络我实测不太稳定，PXE 启动过程对广播和 TFTP 这类协议比较敏感，Wi-Fi 延迟和丢包容易导致启动失败。

2.2 网络规划：DHCP 冲突和固定 IP

这是整个部署里最容易踩坑的一步。PXE 启动第一步是 DHCP，给客户端分配 IP 和启动信息。但 iVentoy 自带 DHCP 服务，而大多数公司、家庭的局域网里已经有路由器在提供 DHCP 了。如果两者同时工作，客户端到底听谁的？这就会造成冲突。

我的建议是，部署前先想清楚 iVentoy 在这个网络里的角色：

• 如果这是一个独立测试网段，没有其他 DHCP 服务器，那可以直接让 iVentoy 开启完整 DHCP 服务，由它来分配 IP。
• 如果局域网里已经有路由器或企业级 DHCP，应该让 iVentoy 使用 DHCP 代理模式，它不直接分配 IP，而是监听 DHCP 请求并“蹭”在应答包里附加 PXE 启动信息。这种方式对现有网络的影响最小。
• 如果你对网络有完全控制权，也可以直接在路由器上关掉 DHCP，让 iVentoy 成为唯一的 DHCP 服务器。但要注意，iVentoy 的核心任务是装机，不适合做复杂 DHCP 策略，生产网络不建议这么干。

还有一点容易被忽略：iVentoy 服务器的 IP 地址务必设置成固定 IP。如果它是 DHCP 分配的，IP 一变，客户端的 PXE 引导就可能失败。方法很简单，在路由器上给服务器做静态 DHCP 绑定，或者在服务器系统里直接配置静态 IP。

2.3 端口清单与防火墙放行策略

iVentoy 运行时会监听多个端口，Docker 部署后这些端口需要能被客户端访问。我整理了一份常用端口清单：

如果你的服务器开着自己的防火墙，需要放行以上端口。如果用 Docker 部署且网络模式选的是 host，那 iVentoy 直接占用宿主机端口，防火墙规则直接按宿主机配置即可。如果管理员对网络安全要求严格，还需要排除 DHCP 和 TFTP 这类协议被防火墙深层检测拦截的情况。

注意：67 端口是 DHCP 标准端口，可能和系统自带的 dnsmasq、dhcpd 冲突。部署前可以用ss -lunp | grep 67检查端口占用，如果被占用，先把原服务停掉。

3. 手把手用 Docker 部署 iVentoy

3.1 准备数据目录与拉取镜像

开始之前确认你的机器已经装好 Docker，并且能正常拉取镜像。如果 Docker 还没装，根据你的系统版本装完再继续。确认没问题后，先创建 iVentoy 的数据目录，这是用来存放配置文件和 ISO 镜像的地方。我习惯放在/data/iventoy：

mkdir -p /data/iventoy

然后从 Docker Hub 拉取 iVentoy 官方镜像。官方镜像在 Docker Hub 上的名称是ventoy/iventoy，建议直接拉 latest 标签，它会跟随官方最新版本更新：

docker pull ventoy/iventoy

拉取完成后可以用docker images确认镜像已经存在。这一过程比较依赖于你的网络环境，如果拉取速度慢，可以配置 Docker 镜像加速器，这个属于 Docker 使用常识，这里不展开讲了。

3.2 启动容器：网络模式和数据卷是关键

启动 iVentoy 容器时，有两个参数直接决定能不能正常工作：网络模式和数据卷。

网络模式我强烈建议直接使用host模式，也就是说容器直接共享宿主机的网络栈，不经过 Docker 的 NAT 转发。为什么这么重要？因为 PXE 启动过程依赖 DHCP 广播和 TFTP，host 模式下容器监听 UDP 67、69 端口和宿主机完全一致，DHCP 广播能够正常处理。如果使用 bridge 模式，Docker 默认的 NAT 和端口映射可能会干扰广播，导致客户端明明在同一个局域网，却始终拿不到 IP。

数据卷方面，把宿主机上的/data/iventoy挂载到容器内的/iventoy，这样镜像和配置都留在宿主机磁盘上，方便管理，也方便以后容器升级时保留数据。

我实际使用的启动命令如下：

docker run -d \ --name iventoy \ --restart unless-stopped \ --net host \ --cap-add NET_ADMIN \ --cap-add SYS_ADMIN \ -v /data/iventoy:/iventoy \ ventoy/iventoy

解释一下这条命令里几个容易忽略的参数：

• --restart unless-stopped：服务器重启后容器自动拉起，避免人为忘记启动。
• --cap-add NET_ADMIN SYS_ADMIN：给容器额外的网络管理和系统管理权限。因为 iVentoy 需要操作网络接口、处理 DHCP 请求、在某些场景下挂载 ISO 镜像，这些操作在 Docker 默认 seccomp 和 cap 限制下会被拦截。实际部署时如果发现 DHCP 服务起不来，优先检查这两个参数有没有加全。

启动完成后，查看日志确认服务是否正常：

docker logs -f iventoy

正常启动时，日志里会输出监听信息，看到类似iVentoy Server started的提示，就说明服务已经跑起来了。此时打开浏览器，访问http://服务器IP:26000，就能看到 iVentoy 的 Web 管理界面。

3.3 浏览器里初始化 iVentoy 并导入镜像

Web 界面打开后，第一件事是设置管理员密码。iVentoy 首次访问会让你初始化一个管理密码，这个密码要记住，之后登录管理界面都要用。

进入主界面后，你会看到几个主要功能标签页：镜像管理、服务设置、客户端列表、系统日志。第一次使用先看“服务设置”，里面会显示 DHCP 服务的状态。如果网络环境适合由 iVentoy 提供 DHCP，直接开启；如果已经有其他 DHCP 服务，选择 DHCP 代理模式，具体选择逻辑我后面单独讲。

接下来导入 ISO 镜像。有两种方式：一是直接把 ISO 文件拷贝到服务器上的/data/iventoy/iso目录，然后在 Web 界面点击刷新；二是通过 Web 界面上传功能，直接从浏览器把 ISO 拖进去。前者适合大批量拷贝，后者适合手里只有一两个镜像时图省事。

我用得最多的方式是直接把镜像拷到 iso 目录，比如：

cp /home/download/ubuntu-server.iso /data/iventoy/iso/

然后在 Web 界面点刷新，镜像列表里就会自动出现这个文件。iVentoy 支持在 iso 目录下建子目录分类，比如按 Windows、Linux、PE 工具分目录存放，客户端启动时看到的菜单也会按目录层级展示，比较清晰。

3.4 用一台客户端验证 PXE 启动

镜像导入完成后，建议先别急着大批量装机，拿一台客户端机器做验证。客户端需要满足一个条件：BIOS 或 UEFI 固件中开启了网卡启动功能。现在大多数台式机和笔记本都支持，通常在 BIOS 的 Boot 选项里找到 PXE Boot / Network Boot / “Realtek PXE B0x D0” 之类的选项，把它调整为第一启动项即可。

客户端开机后，网卡会开始向局域网发送 DHCP 请求。如果 iVentoy 的 DHCP 服务正常工作，客户端会在屏幕上看到获取到 IP 地址的提示，然后进入 iVentoy 的启动菜单。菜单里显示的就是你在 iso 目录里放的所有镜像，用方向键选择、回车确认，之后就能看到系统安装界面。

这一步如果成功，说明整套 PXE 链路已经通了。我第一次部署成功的时候，那种“从开机到进入 Windows 安装界面全程不用插 U 盘”的感觉确实很爽。后面再要装其他机器，就是重复开机、选择镜像、确认安装这几个动作。

4. iVentoy 核心功能解析，这些功能别浪费

4.1 DHCP 模式与 DHCP 代理模式的正确选择

iVentoy 服务设置里有几处容易忽略但至关重要的选项，最核心的是 DHCP 模式。它有三种状态：关闭 DHCP、启用 DHCP、启用 DHCP 代理。

第一种“关闭 DHCP”适合网络里已经有标准 DHCP 服务、且你能在路由器上手动指定 DHCP option 67（启动文件名）的场景。但是说实话，家用路由器基本不给你配 option 67，这种模式对专业网络管理员比较友好。

第二种“启用 DHCP”适合搭建全新测试网段，或者你手头有一个完全受控的交换机/路由器，可以把原 DHCP 关掉。此时 iVentoy 会承担 IP 分配和 PXE 启动信息下发的全部职责。唯一要留意的是别让网络里同时存在两个 DHCP 服务，不然客户端拿到的网关、DNS 可能会乱。

第三种“DHCP 代理模式”是最稳妥的。它监听从客户端发出的 DHCP 请求，当客户端向局域网广播请求时，iVentoy 会在 DHCP 事务中向客户端回复额外的 PXE 启动信息，但实际 IP 地址分配仍然由原有 DHCP 服务器完成。这种模式不抢现有网络的“饭碗”，也不影响非 PXE 启动的设备，适合公司网络和家用路由器环境。我在家里用的就是这种模式，路由器负责分配 IP，iVentoy 只负责告诉客户端“去哪里下载启动文件”，两边互不干扰。

4.2 ISO 镜像管理与架构兼容细节

镜像管理的表面操作很简单，就是放文件、刷新列表。但如果你管理的硬件种类比较复杂，有几个细节要特别注意。

iVentoy 官方的设计目标是支持 x86 和 ARM 架构的 PXE 启动。你可以在同一个镜像目录里同时放入 x86 和 ARM 的 ISO，启动时 iVentoy 会根据客户端的固件架构来自动匹配可引导的镜像。这听起来很酷，但实测中还是要小心：某些 ISO 是纯 x86 版本，比如一些精简版 Windows PE，放在 ARM 机器上选择后可能直接黑屏。所以建议在存放镜像时就按架构建好子目录，在菜单里给目录命名带上架构标识，比如“Windows-x64”、“Linux-arm64”，这样使用的人不容易选错。

另一个容易被忽略的是镜像文件本身是否完整。我在一次部署 Windows Server 时，iso 文件是在网上下载的，大小看着没问题，结果 PXE 引导到一半就卡死。后来把 ISO 在本地用 Ventoy U 盘启动测试，也是同样的问题，才确认是源文件损坏。这个排查思路非常关键：如果你的 iVentoy 引导某个镜像失败，先用 Ventoy 把它做成 U 盘启动试试，如果 U 盘也起不来，那就是 ISO 文件本身的问题，不是 iVentoy 的锅。

4.3 多台并发安装时的资源规划

iVentoy 的一大卖点是可以多台客户端同时安装操作系统。实际执行时，并发数不是无上限的，主要受限于网络带宽和存储 I/O。

举个实际例子，一个 Windows 11 的 ISO 4.8GB，千兆网卡理论传输速度约 100MB/s。如果同时有 10 台机器在拉取镜像，每台实际分到的带宽可能只有 10MB/s 左右，加上安装阶段还有解压、写入等操作，整个安装时长会被明显拉长。所以在大规模装机时，我习惯把机器分批执行，比如一次并发 5 台，完成一批再继续下一批。

存储 I/O 同样重要。如果把 ISO 放在机械硬盘上，同时多台客户端读取大文件，磁盘寻道和缓存会成为瓶颈。我的做法是给 iVentoy 单独准备一个 SSD 目录，或者用 NAS 上的 SSD 存储池来挂载镜像目录。没有 SSD 的环境也没关系，不要一次并发太多机器就行。

另外，iVentoy 管理界面里有一个“客户端列表”标签页，可以看到当前哪些机器正在通过 PXE 启动、选择了什么镜像、传输进度如何。这个功能在批量装机时非常实用，能直观看到现场每台机器的状态，比一台一台去盯屏幕高效得多。配合网刻工具时代老师傅的“看进度条”习惯，iVentoy 的客户端列表就是你的云监控大屏。

5. 常见问题排查：我从踩坑里总结出的速查表

5.1 客户端拿不到 IP 地址

这是最常见的故障，现象是客户端开机后停在 PXE 启动阶段，屏幕上反复提示 “DHCP request” 或者直接卡在网卡初始化。遇到这种情况，按顺序排查：

• 确认容器是否在运行：docker ps | grep iventoy，如果容器没起来，看日志docker logs iventoy。
• 确认 iVentoy 里 DHCP 模式是否打开。如果网络里已有其他 DHCP 且你选择的是完整 DHCP 模式，极大概率是冲突，建议改成 DHCP 代理模式先试。
• 确认防火墙有没有放行 UDP 67、69。这一步在 Docker host 模式下尤其关键，因为容器直接使用宿主机网络，宿主机防火墙要放行对应端口。
• 确认用--net host模式运行。如果之前用 bridge 模式部署，DHCP 广播可能被 Docker 网络隔离，客户端永远找不到 iVentoy。

5.2 能获取 IP 但进不了启动菜单

客户端成功从 DHCP 拿到 IP，说明 DHCP 阶段已经通过。但接下来屏幕上可能显示类似 “TFTP open timeout” 或者一直转圈进不去菜单。这基本是 TFTP 链路出了问题。

排查重点有两个：一是 UDP 69 端口是否通，用ss -lunp | grep 69或抓包工具确认 TFTP 服务在监听；二是客户端和服务器之间是否真的在同一二层网络。我在一次跨 VLAN 测试时就遇到过：客户端能拿到 IP，但 TFTP 被交换机策略拦了，iVentoy 启动文件根本传不过去。如果你的网络里有 VLAN 隔离，PXE 装机服务器和客户端必须放在同一个广播域内，或者交换机上开通相应的 DHCP 中继和跨 VLAN 转发规则。

5.3 安装过程中断、ISO 加载失败

能进菜单，说明 PXE 链路基本没问题。接下来如果选择镜像后黑屏、报错、或者安装一半退出，大多数情况是镜像文件传输中断或 ISO 不完整。先确认服务器磁盘空间是否充足，然后检查网络传输稳定性。

更隐蔽的原因是并发传输时带宽打满导致某个客户端 TFTP/HTTP 连接超时。我自己遇到过 8 台并发时其中一台镜像加载失败，其余 7 台正常的情况。后来调整策略，控制并发不超过 5 台，类似问题就没再出现。如果你是千兆网络，镜像文件又特别大，建议错峰批量操作。

5.4 Docker 容器级的维护与升级

iVentoy 需要升级时，Docker 的方式格外方便。数据卷的好处在这里体现得非常明显。升级流程是：

docker pull ventoy/iventoy docker stop iventoy docker rm iventoy docker run -d \ --name iventoy \ --restart unless-stopped \ --net host \ --cap-add NET_ADMIN \ --cap-add SYS_ADMIN \ -v /data/iventoy:/iventoy \ ventoy/iventoy

因为配置和镜像都在/data/iventoy里，容器删除重建不会影响已有数据和镜像列表。新版启动后，直接打开 Web 界面确认版本号和镜像列表即可。

另外说一个很多人忽略的备份技巧：iVentoy 的配置、日志、镜像列表等信息在数据卷里，但 ISO 文件一般很大，不需要频繁备份。我通常只备份配置文件目录，大约几十 MB。真遇到容器和数据卷都挂了的情况，只要把配置恢复、ISO 重新拷贝回去，整个服务就回来了，整个过程不超过十分钟。

5.5 常见问题速查表

以上这些坑，基本都是我在实际部署和后续维护中踩过的。iVentoy 这个工具本身已经很成熟，多数问题出在网络规划和运行环境上，只要把网络链路搞清楚，它确实能做到“开机即装、选择即安”的体验。我个人的建议是，第一次部署不要直接上大规模生产环境，先用一台普通电脑和 iVentoy 容器搭个最小可用环境，把 DHCP 模式、镜像导入、PXE 启动完整跑通一遍，再去处理批量并发的问题。这套流程走顺之后，你就能随时享受“整个机房一台U盘都不用插”的快乐了。