2026/9/20 17:17:29
FEATURED · 精选文章 
整天拿着 U 盘一台一台插着装系统干过的人都懂是什么滋味先从这台机器把系统装完再抱着 U 盘走到下一台中间还要担心 ISO 版本不对、U 盘启动被 BIOS 拦、装机过程中盘符错乱。那如果是一次要处理十几台相同配置的机器呢这就轮到 PXE 网络装机上场了。可传统 PXE 要自己搭 DHCP、TFTP、文件服务再手写启动菜单光是把链路跑通就够劝退一批人。iVentoy 想解决的就是这个尴尬它把 PXE 服务的复杂度基本抹平你用 Docker 把它跑起来之后唯一要做的就是往目录里丢几个 ISO 文件。这篇文章我会从部署、使用、排错三个角度把基于 Docker 搭建 iVentoy PXE 网络装机平台的完整过程逐步拆开讲适合机房维护、实验室管理、NAS 玩家以及所有不想在 PXE 配置上浪费时间的折腾党。1. iVentoy 是什么为什么我要用它替代传统 PXE 方案1.1 PXE 传统链路到底麻烦在哪PXEPreboot 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 引导阶段。端口协议用途26000TCPWeb 管理控制台26001TCPISO 文件传输服务26002TCP辅助/备用文件传输服务67/68UDPDHCP 地址分配开启 iVentoy DHCP 时使用69UDPTFTP 引导文件下发实际使用中如果采用 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 网络模式也就是让容器共享宿主机网络栈。原因有三PXE 的 DHCP 广播能直接在本网段内被 iVentoy 接收不用经过 Docker 的 NAT 转换。端口不冲突时不需要手动写一堆端口映射配置更直观。客户端访问 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 \ --restartalways \ -v /opt/iventoy/data:/data \ iventoy/iventoy:latest这里面的几个参数解释一下-d后台运行。--network host使用宿主机网络这是 PXE 服务能正常工作的关键。--restartalways容器异常退出或宿主机重启后自动拉起装了一半系统服务挂了那体验确实有点闹心。-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.ymlservices: 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 -dCompose 会自己判断是否需要重建容器换新服务器时把 yml 文件和 /opt/iventoy/data 目录一起拷过去直接拉起来就是一模一样的环境。3.3 以飞牛 NAS 为例的图形化部署现在很多 NAS 系统内置了 Docker 管理界面以飞牛 NASfnOS为例整体流程非常直观打开 NAS 的 Docker 应用在镜像页面搜索iventoy/iventoy并拉取。进入容器创建页面填写容器名称选择刚才拉取的镜像。存储空间设置里把 NAS 上的一个共享文件夹映射到容器的/data目录今后把 ISO 直接拷到这个共享文件夹即可。网络模式选择 host。这里特别提醒如果 NAS 的 Docker 界面默认是 bridge需要手动切到 host不然 PXE 广播很难正常到达容器。设置重启策略为“容器退出时自动重启”保存并启动容器。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 给了两种思路iVentoy 自己分配地址在 Web 控制台里启用 DHCP 功能设置地址池、掩码、网关和 DNS。这种模式适合“完全隔离的测试环境”比如一个独立交换机、没有插到公司主网络。现实落地时办公网络环境通常不建议这么干会和路由器的 DHCP 打架。proxyDHCP 模式让现有 DHCP 服务器继续分 IPiVentoy 只作为“代理 DHCP”响应 PXE 客户端的特殊请求。理解成客户端的 IP 还是由路由器分但启动信息由 iVentoy 补充。正常办公网络推荐这种模式不需要动路由器配置。如果客户端和 iVentoy 不在同一个二层网络默认 proxyDHCP 通常收不到广播这时需要在三层交换机或防火墙上配置 DHCP Relaydhcp relay / ip helper-address把启动请求转发到 iVentoy 所在网段。很多“能蹭到网络但死活引导不起来”的诡异问题最后都能定位到跨 VLAN 这一步。4.3 首次网络引导的全过程一切就绪后客户端从 PXE 启动屏幕会依次出现网卡初始化显示 “Start PXE over IPv4” 之类的字样。客户端获取到 IP 地址同时收到 iVentoy 下发的启动信息。自动加载引导菜单几秒后进入一个类似 Ventoy 的图形界面。选择要安装的 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.isoiVentoy 默认会按照子目录结构展示菜单分类清晰现场选镜像也快。命名上建议把版本号和架构写清楚避免出现两个 “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 阶段。排查链路可以这样走先在 Web 控制台确认 iVentoy 服务正常并确认它处于允许提供启动服务的状态。确认客户端和服务器在同一广播域。最简单的测试方法是在客户端所在网络内用另一台电脑访问http://宿主机IP:26000能访问说明三层可达不能访问说明跨了 VLAN。检查 DHCP 应答。如果局域网里路由器 DHCP 和 iVentoy 的 proxyDHCP 同时存在某些异常情况下客户端只认到了普通 DHCP 应答、没认到 PXE 扩展。这种时候可以在 iVentoy 里手动切换模式或者临时关掉路由器的 DHCP 做对照试验。有条件就抓包。在宿主机执行tcpdump -i 网卡名 udp port 67 or port 68 or port 69看看客户端广播有没有到达、iVentoy 有没有回应。抓包是定位 PXE 类问题最快的手段比盲目改配置高效得多。6.2 Web 控制台能开但客户端根本拿不到 IP这个现象更常见于 bridge 网络模式或者宿主机防火墙配置异常。我的检查顺序是查看容器是否真的在运行docker ps。确认26000端口能访问说明容器进程正常。检查宿主机防火墙是否拦截 UDP 67/68/69。很多 Linux 发行版默认防火墙规则只放行 22 端口和一些常用服务一定要手动放行 iVentoy 相关端口。检查 iVentoy 的地址池设置。如果现有网段是192.168.1.0/24而 iVentoy 地址池错配成192.168.0.0/24客户端即使收到 DHCP Offer 也大概率不会使用这个地址。如果网络拓扑里还有其他 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 功能没装好。处理方式是在任务管理器 - 性能 - CPU 里看“虚拟化”状态如果显示“已禁用”需要进 BIOS 开启 Intel VT-x 或 AMD-V。Windows 功能里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统WSL2”装完重启。安装 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 直接放在共享目录里日常维护几乎零成本。
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 传统链路到底麻烦在哪PXEPreboot 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 引导阶段。端口协议用途26000TCPWeb 管理控制台26001TCPISO 文件传输服务26002TCP辅助/备用文件传输服务67/68UDPDHCP 地址分配开启 iVentoy DHCP 时使用69UDPTFTP 引导文件下发实际使用中如果采用 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 网络模式也就是让容器共享宿主机网络栈。原因有三PXE 的 DHCP 广播能直接在本网段内被 iVentoy 接收不用经过 Docker 的 NAT 转换。端口不冲突时不需要手动写一堆端口映射配置更直观。客户端访问 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 \ --restartalways \ -v /opt/iventoy/data:/data \ iventoy/iventoy:latest这里面的几个参数解释一下-d后台运行。--network host使用宿主机网络这是 PXE 服务能正常工作的关键。--restartalways容器异常退出或宿主机重启后自动拉起装了一半系统服务挂了那体验确实有点闹心。-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.ymlservices: 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 -dCompose 会自己判断是否需要重建容器换新服务器时把 yml 文件和 /opt/iventoy/data 目录一起拷过去直接拉起来就是一模一样的环境。3.3 以飞牛 NAS 为例的图形化部署现在很多 NAS 系统内置了 Docker 管理界面以飞牛 NASfnOS为例整体流程非常直观打开 NAS 的 Docker 应用在镜像页面搜索iventoy/iventoy并拉取。进入容器创建页面填写容器名称选择刚才拉取的镜像。存储空间设置里把 NAS 上的一个共享文件夹映射到容器的/data目录今后把 ISO 直接拷到这个共享文件夹即可。网络模式选择 host。这里特别提醒如果 NAS 的 Docker 界面默认是 bridge需要手动切到 host不然 PXE 广播很难正常到达容器。设置重启策略为“容器退出时自动重启”保存并启动容器。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 给了两种思路iVentoy 自己分配地址在 Web 控制台里启用 DHCP 功能设置地址池、掩码、网关和 DNS。这种模式适合“完全隔离的测试环境”比如一个独立交换机、没有插到公司主网络。现实落地时办公网络环境通常不建议这么干会和路由器的 DHCP 打架。proxyDHCP 模式让现有 DHCP 服务器继续分 IPiVentoy 只作为“代理 DHCP”响应 PXE 客户端的特殊请求。理解成客户端的 IP 还是由路由器分但启动信息由 iVentoy 补充。正常办公网络推荐这种模式不需要动路由器配置。如果客户端和 iVentoy 不在同一个二层网络默认 proxyDHCP 通常收不到广播这时需要在三层交换机或防火墙上配置 DHCP Relaydhcp relay / ip helper-address把启动请求转发到 iVentoy 所在网段。很多“能蹭到网络但死活引导不起来”的诡异问题最后都能定位到跨 VLAN 这一步。4.3 首次网络引导的全过程一切就绪后客户端从 PXE 启动屏幕会依次出现网卡初始化显示 “Start PXE over IPv4” 之类的字样。客户端获取到 IP 地址同时收到 iVentoy 下发的启动信息。自动加载引导菜单几秒后进入一个类似 Ventoy 的图形界面。选择要安装的 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.isoiVentoy 默认会按照子目录结构展示菜单分类清晰现场选镜像也快。命名上建议把版本号和架构写清楚避免出现两个 “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 阶段。排查链路可以这样走先在 Web 控制台确认 iVentoy 服务正常并确认它处于允许提供启动服务的状态。确认客户端和服务器在同一广播域。最简单的测试方法是在客户端所在网络内用另一台电脑访问http://宿主机IP:26000能访问说明三层可达不能访问说明跨了 VLAN。检查 DHCP 应答。如果局域网里路由器 DHCP 和 iVentoy 的 proxyDHCP 同时存在某些异常情况下客户端只认到了普通 DHCP 应答、没认到 PXE 扩展。这种时候可以在 iVentoy 里手动切换模式或者临时关掉路由器的 DHCP 做对照试验。有条件就抓包。在宿主机执行tcpdump -i 网卡名 udp port 67 or port 68 or port 69看看客户端广播有没有到达、iVentoy 有没有回应。抓包是定位 PXE 类问题最快的手段比盲目改配置高效得多。6.2 Web 控制台能开但客户端根本拿不到 IP这个现象更常见于 bridge 网络模式或者宿主机防火墙配置异常。我的检查顺序是查看容器是否真的在运行docker ps。确认26000端口能访问说明容器进程正常。检查宿主机防火墙是否拦截 UDP 67/68/69。很多 Linux 发行版默认防火墙规则只放行 22 端口和一些常用服务一定要手动放行 iVentoy 相关端口。检查 iVentoy 的地址池设置。如果现有网段是192.168.1.0/24而 iVentoy 地址池错配成192.168.0.0/24客户端即使收到 DHCP Offer 也大概率不会使用这个地址。如果网络拓扑里还有其他 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 功能没装好。处理方式是在任务管理器 - 性能 - CPU 里看“虚拟化”状态如果显示“已禁用”需要进 BIOS 开启 Intel VT-x 或 AMD-V。Windows 功能里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统WSL2”装完重启。安装 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 直接放在共享目录里日常维护几乎零成本。 
