装系统的活儿干过的人都懂单台电脑用 U 盘慢慢磨没问题可一旦面对几十台甚至上百台机器逐个插 U 盘、按 F12、选启动项、再等镜像拷贝心态很容易崩。我第一次被逼着搞 PXE 网络装机是因为新办公室一下子到了四十多台整机第二天就要统一交付 Windows 和 Ubuntu 双系统环境。手头 U 盘不是容量不够就是引导坏了后来一跺脚直接上 PXE。传统 PXE 方案配置链路长DHCP、TFTP、HTTP、引导菜单一个个搭光是排错就花了一个下午。直到我遇到 iVentoy配合 Docker 部署不到十分钟就把一个完整的 PXE 网络装机平台拉起来了。这篇文章就是一次完整的实战记录从原理、部署、配置到踩坑排查一次性讲清楚给正准备搞批量装机的运维同学一个可以直接抄作业的参考。1. iVentoy 是什么先把它和 Ventoy、传统 PXE 的关系捋清楚1.1 从 Ventoy 到 iVentoy一个本地 U 盘工具的网络化进化Ventoy 在系统维护圈子里的知名度相当高很多人兜里都揣着一个装好 Ventoy 的 U 盘日常装系统、进 PE 都靠它。Ventoy 的思路很巧妙把 U 盘格式化成专用格式后你只要把 ISO 镜像文件直接复制进去开机就会自动弹出一个引导菜单选哪个镜像就启动哪个完全不用反复烧录。iVentoy 就是 Ventoy 团队在同一个思路上做的网络版。核心逻辑没变镜像文件直接存放在服务器目录里但把“U 盘”换成了“局域网”把“本机引导”换成了“PXE 网络引导”。客户端电脑开机后从网卡启动通过网络获取引导菜单选定要安装的 ISO再由服务器通过 HTTP 协议把镜像内容传送过去完成启动和安装。这个设计最讨喜的地方在于它没有试图做一个“全功能集成安装系统”而是老老实实把“镜像存放”和“网络引导”这两件事做好。你不需要关心 PXE 协议栈怎么实现不需要手动生成引导配置文件只要把 ISO 往目录里一放剩下的事情交给 iVentoy 去处理。无论是 Windows、Ubuntu、Debian、Rocky Linux还是各种 PE 维护盘、LiveCD只要能通过 ISO 启动就能通过它网络引导。1.2 PXE 网络装机的基本链路为什么传统方案又臭又长要说清楚 iVentoy 的价值得先搞清楚传统 PXE 引导到底做了哪些事。PXE 是 Intel 定义的网络启动协议整个流程可以拆成四步第一步客户端开机网卡在局域网内发一个 DHCP 广播申请 IP 地址。普通家用路由器只会返回 IP、网关和 DNS但 PXE 场景下DHCP 服务器还必须额外返回两个关键信息下一跳服务器地址也就是 next-server通常是 TFTP 服务器和需要下载的引导文件名。第二步客户端拿到这些信息后通过 TFTP 协议去下载引导文件。TFTP 是一个非常古老且简单的协议没有认证、速度也慢但优点是可靠这个阶段传输的文件通常只有几百 KB慢一点也感觉不出来。第三步引导文件被加载后会继续通过网络读取一个菜单配置文件把可引导的镜像列表展示出来。用户选择某个镜像后引导程序把内核和 initrd 加载进内存。第四步内核起来后安装程序需要继续从服务器读取 ISO 内容这里通常用到 HTTP、NFS 或 iSCSI 协议。传统环境下搭这么一套意味着你要同时维护 DHCP 服务、TFTP 服务、HTTP 服务还要处理不同的引导文件格式、UEFI 和 Legacy 的差异、菜单语法规则。任何一个环节配错客户端启动就会像断了线的风筝什么提示都不给。iVentoy 做的事情就是把这四步全部接管内置 DHCP 分配功能内置 TFTP 服务内置 HTTP 数据服务引导菜单直接生成你只需要在网页上勾选哪个镜像可用。1.3 iVentoy 的适用场景与边界根据我自己的使用体感下面这几类场景特别适合 iVentoy。第一类是新电脑批量初始化。公司进了一批机器要统一装系统用 PXE 并发安装比一个 U 盘轮转快太多了安装速度主要受限于网络和磁盘人工干预基本为零。第二类是机房和实验室的日常重装。学生上课折腾坏了系统管理员随时重装一台机器从开机到进入系统安装界面约十几分钟人还不累。第三类是测试环境快速交付。需要临时验证某个 Linux 发行版、启动一个 WinPE把 ISO 丢进数据目录即时可用。边界也很清晰。iVentoy 是局域网工具跨 VLAN 使用需要配置 DHCP Relay普通交换机做不到开箱即用。它只负责把 ISO 引导起来不负责驱动注入、自动应答、软件分发这些装完系统之后的事情。另外如果局域网里已有严格的 DHCP 服务直接启动它的内置 DHCP 会引发冲突这个我在后面专门讲。2. 为什么用 Docker 来跑 iVentoy而不直接跑二进制2.1 一条命令拉起服务升级和迁移都省心iVentoy 官方其实提供了 Linux 二进制包解压后修改配置就能直接运行。但我还是推荐用 Docker理由很实际。一是依赖环境干净。iVentoy 虽然不依赖太多系统库但你保不齐要把它跑在 Ubuntu、CentOS、Debian 或者是 NAS 的容器环境里系统版本一换兼容性问题就可能冒出来。Docker 镜像把运行环境固化住了同一份镜像在任何能跑 Docker 的机器上行为一致。二是升级和回滚方便。裸装方式升级 iVentoy需要先停止服务、备份数据、替换二进制、再启动操作繁琐且容易出错。用 Docker 升级就是改一下镜像 tag或者直接复用原来的端口和数据目录启动一个新容器几分钟搞定。万一新版本有坑还能迅速换回旧镜像。三是资源控制和日志聚合。Docker 自带docker logs命令看实时日志很顺手。还可以通过--memory、--cpus限制容器资源防止在 NAS 那种小设备上把 CPU 吃满。对于追求省心的运维选手这些都是实打实的加分项。2.2 host 网络模式是 PXE 能工作的核心前提这里必须重点强调网络模式。我第一次部署时想当然写了标准的-p 26000:26000 -p 69:69/udp -p 67:67/udp端口映射Web 管理页面确实能打开但客户端从网卡引导时始终卡在 DHCP 阶段日志里连一条请求都看不到。排查了很久才发现问题出在 Docker 默认的 bridge 网络模式上。PXE 的早期阶段依赖广播消息客户端发送的 DHCP 请求是发到整个网段的。在 bridge 网络模式下容器处于一个隔离的 NAT 子网里广播包不会原样转发到物理局域网单纯映射 UDP 端口也无法满足 DHCP 协议的行为要求。iVentoy 必须直接监听宿主机物理网卡才能收到客户端的广播、正确回应 DHCP Offer。所以部署 iVentoy 时容器网络模式建议直接使用host。host 模式下容器和宿主机共享网络栈没有端口映射的问题DHCP、TFTP、HTTP 全都走物理网卡行为和裸装程序完全一致。这个教训是我整个部署过程中踩过最大的坑写出来就是希望大家别再走一遍。2.3 数据目录规划镜像、配置、日志要分清楚Docker 部署有状态服务数据卷规划一定要提前想明白。iVentoy 容器内有一个/data目录里面存放镜像、配置和日志。我的做法是在宿主机建目录/opt/iventoy/data然后用-v挂载进去让所有数据落在宿主机上。挂载时有个性能细节需要注意iVentoy 的 Web 界面同步镜像、多个客户端并发读取 ISOIO 压力都在这个数据目录上。如果条件允许尽量放在 SSD 上。我最早把 ISO 放在机械硬盘上同时让 10 台机器拉同一个 Windows 镜像机械硬盘随机读取能力直接顶不住每台机器的下载速度都掉到 20MB/s 左右。换成 SSD 之后同时 20 台机器并发千兆网卡下每台基本都能稳定跑到 80MB/s 以上。目录结构上我不建议在数据目录里嵌套太深的层级。iVentoy 会递归扫描镜像目录但层级太深在 Web 界面里显示路径太长找起来费力。我的习惯是按系统类型分一层子目录比如Windows/、Linux/、PE/每个子目录里直接放对应 ISO 文件简洁明了。3. 手把手部署 iVentoy从拉取镜像到第一台机器被网络引导3.1 部署前要确认的环境条件开始操作之前先确认三件事。一是 Docker 服务正常。执行docker version分别查看客户端和服务器版本确认 Docker daemon 已经启动。如果之前安装过旧版 Docker建议提前升级新的镜像层特性对老版本兼容性不太好。二是给宿主机规划一个固定 IP。iVentoy 服务器必须有一个稳定的局域网地址最好在路由器或 DHCP 服务器里做静态绑定。我这里用192.168.50.100作为示例实际部署时换成你自己环境里的地址。三是创建数据目录。执行mkdir -p /opt/iventoy/data这个目录后面会挂载进容器。如果你有一块独立数据盘也建议挂载到这个路径保证 ISO 读取和系统盘 IO 互不干扰。3.2 docker run 命令逐项拆解环境准备妥当后我直接运行下面的命令启动容器docker run -d \ --name iventoy \ --restart unless-stopped \ --net host \ -v /opt/iventoy/data:/data \ ventoy/iventoy:latest逐项解释一下-d后台运行日志交给 Docker 管理。--name iventoy给容器起名后续docker logs iventoy、docker restart iventoy都靠这个名字。--restart unless-stopped容器异常退出或宿主机重启后自动拉起适合做长期服务。--net hosthost 网络模式PXE 广播和 DHCP 正常工作的前提原因前面说过。-v /opt/iventoy/data:/data数据卷挂载镜像和配置持久化到宿主机。ventoy/iventoy:latest官方镜像。这里有个细节镜像名和版本 tag 要以你拉取时的 Docker Hub 页面说明为准不同时期官方可能调整仓库地址生产环境建议指定明确版本号不要长期追 latest。启动后执行docker ps看到容器状态是 Up 就说明服务起来了。然后在浏览器打开http://192.168.50.100:26000看到 iVentoy 的 Web 管理界面即部署成功。如果你习惯用 Docker Compose 管理服务也可以写一份docker-compose.ymlservices: iventoy: image: ventoy/iventoy:latest container_name: iventoy restart: unless-stopped network_mode: host volumes: - /opt/iventoy/data:/data在该文件所在目录执行docker compose up -d效果和上面的docker run完全一致。Compose 的好处是配置沉淀成文件换服务器时直接备份这个 YAML 和数据目录就能完整复现整套环境。3.3 添加 ISO 镜像并完成首次 PXE 启动服务跑起来之后第一件事就是把 ISO 镜像放进去。两种方式任选一是直接把 ISO 文件复制到/opt/iventoy/data/iso目录二是登录 Web 界面在镜像管理页上传。大文件我更喜欢用 scp 或 sftp 直接拷入目录上传过程更稳定不会因为浏览器页面超时导致传输中断。放置完成后回到 Web 界面点击“同步”iVentoy 会扫描 iso 目录识别出新出现的镜像。同步完成后镜像列表里就能看到刚才放入的 ISO默认是启用状态。接下来做一次完整的 PXE 启动测试。我找了一台测试电脑开机按快捷键进启动菜单选择从网卡启动通常显示为 PXE 或 IPv4 Network Boot 字样。客户端随即发送 DHCP 广播iVentoy 响应分配一个 IP 地址然后自动加载引导文件。此时屏幕上会出现 iVentoy 的引导菜单列出所有可用的 ISO 镜像。我用方向键选中一个 Ubuntu 的 Live ISO回车大约两分钟后看到 Ubuntu 桌面加载出来首次网络引导成功。从拆开新机器包装到进入安装界面全程没有插过 U 盘也没有在每台电脑前蹲守这种感觉确实不一样。4. 界面、配置与日常运营细节4.1 Web 管理界面镜像、客户机、日志三大块怎么用iVentoy 的 Web 管理界面做得简洁并没有塞满花哨功能核心就三块。镜像管理区用来维护可用的 ISO 列表可以对每个镜像做启用、停用、备注、排序操作。批量装机的场景里我经常把不常用的 PE、LiveCD 临时停用避免安装人员误选。客户机管理区是最有存在感的一块。这里能看到当前所有由 iVentoy 引导的客户端包括它们的 IP、MAC 地址、当前引导状态和实时传输速度。批量装机时我会在这里盯一会儿确认每台机器都进入了安装阶段而不是卡在引导环节。如果某台机器传输速度为 0 且持续很久就要考虑是网线问题还是镜像问题。日志区记录每一次引导请求的详细过程包含时间戳、客户端 MAC、请求的镜像、错误码等信息。这是排查问题的一手线索后面讲问题处理时还会提到。需要注意的是容器默认时区可能是 UTC日志时间比北京时间慢 8 小时建议启动容器时加上-e TZAsia/Shanghai环境变量校准时间。4.2 配置文件 config.json 里的关键项iVentoy 的配置信息以 JSON 格式存放在数据目录下容器启动时读取。我的使用习惯是能通过界面改的设置不在配置文件里动只有需要批量修改或者做脚本化部署时才会直接编辑配置文件。几个关键配置项按我的理解说一下作用。DHCP 相关的配置项决定内置 DHCP 服务的行为包括是否启用、分配的地址池范围、子网掩码、默认网关等。如果 iVentoy 跑在一个独立网段默认配置基本够用。如果跑在已有 DHCP 的办公网需要关闭内置 DHCP 或者使用共存方案后面详细说。Web 访问验证相关的配置项可以给管理界面添加账号密码保护。在人员比较杂的环境里强烈建议开启避免有人恶作剧把可用镜像全部停用影响正常装机任务。日志级别相关的配置项可以切换日志的详细程度。排错时调到最详细日常建议保持默认避免日志文件增长太快。编辑配置文件前先备份一份改完后重启容器因为服务运行中可能会把内存里的配置覆盖回去。我习惯用docker cp先把容器内的配置文件复制出来备份一份改坏了随时恢复。4.3 和现有 DHCP 共存一个必须提前想清楚的架构决策这是整个部署中最容易引发生产事故的点单独拿出来说。iVentoy 默认启用内置 DHCP 服务如果你把它部署在一个已有 DHCP 服务器的局域网里会出现两台 DHCP 服务抢应答的情况。客户端可能先收到路由器发的响应也可能先收到 iVentoy 发的响应IP 分配混乱甚至会波及整个网络里的正常设备。我亲自踩过一次在办公网里测试 iVentoy忘记关闭内置 DHCP结果整个楼层的设备都收到了 iVentoy 发来的 DHCP Offer网关信息还是我随手填的差点把办公网 IP 地址池搞乱。两种解决方案比较靠谱。第一种是使用独立网段。iVentoy 所在的交换机只连接需要 PXE 装机的客户端与办公网物理隔离这样内置 DHCP 就不会影响到其他设备。这是我的首选方案尤其是在长期使用的机房环境里一次规划好后面省心。第二种是关闭内置 DHCP借助 DHCP Relay 转发 PXE 请求。现有 DHCP 服务器负责分配 IP同时配置 next-server 参数指向 iVentoy 服务器地址以及 boot-file 参数指向引导文件名。iVentoy 只负责提供引导文件和数据传输服务。这个方案需要交换机支持 DHCP Relay 配置对网络管理员有一定要求小团队不一定能搞定。4.4 性能与存储多客户端并发时如何不拖后腿并发安装时瓶颈大多数时候在磁盘 IO而不是网络带宽。ISO 文件本身是大文件顺序读取如果同时有十几台机器读取同一个镜像磁盘就要同时响应多个读取请求机械硬盘在这种随机并发场景下表现很差。这也是我前面反复强调数据目录放到 SSD 的原因。网络方面千兆交换机同时引导二十台机器每台机器分到的带宽仍然够用系统安装的主要时间消耗在写盘阶段下载速度再快也弥补不了机械硬盘的写入时间。如果机器数量特别多可以用万兆交换机或者把镜像拆分到多个数据目录、起多个 iVentoy 实例分散压力。不过对绝大多数场景来说一个实例加 SSD 镜像存储已经完全够用。还有一个小细节镜像在数据目录里不要直接放在根目录与配置文件混在一起我习惯建一个专门的iso子目录这样在备份数据目录时也很清楚哪些是需要保留的镜像文件。5. 常见问题排查与实用避坑清单5.1 客户端拿不到 IP或者一直卡在 DHCP最典型的故障现象是客户端开机后停在 DHCP 阶段屏幕显示 “No boot filename received” 或者干脆没有反应。我的排查流程是固定的。先确认容器状态执行docker ps看 iVentoy 是否在运行。再看 Web 界面日志里有没有出现客户端的请求记录。如果日志里完全空白说明客户端的 DHCP 请求没有到达 iVentoy 容器重点检查两件事容器网络模式是不是 host以及宿主机防火墙有没有放行 UDP 67 和 UDP 69 端口。我在 CentOS 上遇到过一次防火墙默认放行了 TCP 流量但 UDP 67、69 没有放行客户端一直卡在 DHCP。用firewall-cmd --add-servicedhcp --add-servicetftp按服务方式加放行规则问题立刻解决。另外宿主机如果有多个网卡还要留意 iVentoy 是否绑定了客户端所在的物理网卡虚拟网卡上的广播包通常不会转发到物理局域网。5.2 镜像能引导但进入安装界面报错或退出有些 ISO 能正常出现 iVentoy 菜单但选择后进入安装程序就报错。这种情况大多不是 iVentoy 的问题而是镜像本身对网络引导方式的兼容性差异。Windows 系统强烈建议用官方原版镜像网上各种精简优化的第三方镜像在 PXE 环境下的出错概率明显更高。Linux 发行版里Ubuntu、Debian 官方镜像兼容性最好CentOS Stream、Rocky Linux 也基本没有坑但某些基于 Ubuntu 二次封装的发行版改了内核参数或者裁剪了驱动可能在挂载 HTTP 安装介质时失败。排查时先用一个纯净的官方镜像测试基本能确认是不是镜像自身的兼容性问题。另一点和 iVentoy 无关但实际装机流程里非常影响体验品牌机和某些工作站默认把硬盘模式设置成 RAIDWindows 安装时会提示“找不到硬盘”。需要在 BIOS 里把硬盘模式改成 AHCI或者提前在 Windows 安装镜像里注入对应 RAID 驱动。5.3 UEFI 与 Secure Boot 的兼容处理现在的机器基本都是 UEFI 引导默认还开着 Secure Boot。iVentoy 对 UEFI 引导有适配但个别主板的安全策略比较严格可能会在加载引导文件时被拦截提示安全策略校验失败。最直接的解决办法是进 BIOS 关闭 Secure Boot。对于批量装机环境来说关闭 Secure Boot 并不影响系统安装反而能减少大量兼容性问题。如果项目有合规要求必须保留 Secure Boot可以参考 iVentoy 官方文档里关于证书信任的说明把引导文件加入主板信任列表但这个操作在批量部署时效率太低如果不是硬性要求不推荐优先考虑。还需要注意 UEFI 和 Legacy 引导模式切换的问题。一台机器如果之前用 Legacy 模式装过 Windows后来改成 UEFI 模式通过网络引导装新系统很可能因为磁盘分区表格式不匹配导致安装失败。建议在交付方案里统一规划引导模式新机器全部 UEFI老机器保持 Legacy不要在同一个机房混着改。5.4 容器日志与数据卷权限的几个坑排查 iVentoy 问题第一步永远是docker logs iventoy。常见做法是先用docker logs --tail 200 iventoy看最后 200 行日志如果没有线索再开一个终端执行docker logs -f iventoy实时观察同时让一台测试客户端发起引导看日志里有没有新的连接记录。容器层面还常遇到数据卷权限问题。把数据目录挂载进容器后如果 iVentoy 无法创建日志文件或者同步镜像列表时报 Permission denied容器可能反复重启。这种问题通常是宿主目录的属主和容器内运行用户的 UID 不匹配导致的。解决办法是查看容器文档里指定的用户 UID用chown调整宿主目录属主不要偷懒直接 chmod 777否则后续目录里文件越来越多权限问题会越来越难收拾。还有一个经常被忽略的坑iVentoy 容器默认时区是 UTC日志和 Web 界面显示的时间比北京时间慢 8 小时排查问题时时间对不上很别扭。启动容器时加上-e TZAsia/Shanghai把时区校准到本地时间。5.5 用得最多的排查命令速查表我把实际运维中反复使用的查验命令整理成一张表方便直接对照。命令用途docker ps确认容器状态是否正常docker logs -f iventoy实时查看 iVentoy 运行日志docker restart iventoy修改配置后重启容器docker exec -it iventoy ls /data/iso进入容器查看镜像目录firewall-cmd --list-all确认宿主机防火墙放行情况ss -ulpngrep 67ss -tlpngrep 26000最后分享一个我自己养成的习惯每次批量装机任务结束后会在 Web 界面把不常用的镜像停用同时抽查一次客户端引导记录确认平台处于健康状态。iVentoy 平时用起来确实很省心但它承担的是关键时刻几十台机器的交付任务平时多留一份心真正用的时候才不慌。希望这篇实战记录能帮你少走一些弯路。
