告别 Proxmox，迁移至 NixOS + Incus：体验声明式管理的高效与可重现性！

全面转向 Nix：从 Proxmox 到 NixOS + Incus

为何用声明式文本文件取代了可点击操作的虚拟机管理程序？

最后更新于 2025 年 12 月 01 日，阅读时长 9 分钟 软件开发，DevOps，家庭实验室

已正式停用了 Proxmox 集群。多年来，家庭实验室一直运行在 Proxmox 上，从最初的一台 NUC 扩展到多节点集群，如今已将所有内容迁移到了运行 Incus 的 NixOS 上。

从怀疑者到信徒

并非一开始就是 Nix 的拥护者。实际上，最初十分讨厌 Nix 语言及其语法，完全搞不懂它的工作原理，而且已有自己设置 dotfiles 的特定方式。使用 Dotbot 进行符号链接，还用自己编写的名为 dotbins 的工具来管理二进制文件。觉得大多数工具并不需要 Nix。在 Mac 上使用 nix - darwin 很长时间，但也只是用它来指定 Homebrew 软件包和应用程序设置。

真正让态度转变的是购买游戏电脑的时候，正如在本地大语言模型文章中所描述的那样。起初，安装了 Pop!_OS，因为想玩游戏，同时又坚决不想用 Windows。虽然有些游戏能运行，但不断遇到 NVIDIA 驱动问题，需要运行一些随机的命令式命令来解决。觉得这不是个好办法，因为之后根本无法重现这些调试步骤。后来，做了件蠢事，更新了 NVIDIA 驱动，却没意识到命令式地管理驱动版本和存储库会带来灾难，结果陷入了 GRUB 启动循环。沮丧之下，安装了 NixOS，希望它承诺的原子更新能解决这个问题。结果令人惊喜。在将系统迁移到新磁盘之前，从未真正相信一切能做到字节级的完全一致。没有克隆磁盘，只是将 Nix 配置应用到全新安装中。系统顺利启动，复制了数据，一切都和原来一模一样。那一刻，彻底信服了。

命令式系统的弊端

Proxmox 是一款很棒的软件。它降低了入门门槛，教会了几乎所有关于虚拟化、LXC 容器和 ZFS 的知识。但从根本上说，Proxmox 是围绕“点击按钮”构建的，是一种以图形用户界面（GUI）优先的模式。虽然可以使用 Terraform 或 Ansible 来自动化操作，但这往往感觉像是在和工具较劲。状态漂移是真实存在的问题。在界面中更改某个设置来调试问题，之后就忘了，六个月后，“基础设施即代码”就与实际情况不一致了。对于手动维护系统的人来说，这很烦人。但当引入 AI 代理时，这对操作者来说就成了灾难。以“大胆模式”运行的代理可能会执行数百条命令式命令来解决问题。它可能会成功，但会让系统处于一种未定义、不可重现的状态，甚至连代理自己都无法完全理解或复制。

这种弊端在硬件管理方面也有所体现。在 HP EliteDesk 上，Intel I219 - LM 网卡有个已知的 bug，开启硬件卸载时会挂起。隐约记得几年前在 Proxmox 上解决过这个问题，但具体细节已经忘了。当安装 NixOS 时，又遇到了同样的问题：网络会随机断开。不过这次，解决办法不是在 root shell 历史记录中遗忘的命令，而是配置中有文档记录的 systemd 服务。添加了注释，详细解释了为什么需要 `tso off gso off`，还引用了相关论坛帖子。如果重新安装这台机器，问题会自动解决。而在 Proxmox 上，又得重新经历一遍痛苦的排查过程。

另一个例子是 Intel NUC。由于家庭实验室设备放在电视后面，就想能不能把它也用作家庭影院电脑（HTPC）。在 Proxmox 上，这需要将 GPU 直通到虚拟机才能获得视频输出。但这样做意味着 Proxmox 主机将完全无法访问 GPU，一旦出现问题就无法使用本地控制台。这是一个严格的二选一：要么是媒体播放器，要么是可调试的虚拟机管理程序。试过，但太麻烦了，很快就放弃了。有了 NixOS，就不用做选择了。主机操作系统直接运行 Kodi，提供原生硬件加速和视频输出。同时，`incus` 在后台运行，托管容器。在同一台设备上既能拥有 HTPC，又能拥有服务器，还没有虚拟化开销或“无头主机”的限制。

还有更深层次的哲学差异。像 Proxmox 或 TrueNAS 这样的系统被设计成设备形式。不建议在主机上运行任意命令，安装软件包或调整配置文件也不受鼓励，因为这样可能会破坏中间件，或者在升级时丢失更改。实际上，无法充分发挥自己硬件的全部潜力。而在 NixOS 上，主机完全由自己掌控。可以随意折腾它，比如安装 Kodi、调整网络驱动、运行本地大语言模型，而不用担心出问题。因为状态是声明式的，一切都清晰明了且可重现。即使主机配置出现问题，即使机器正在运行重要服务，也能在几秒钟内恢复到正常状态。

代理式编程的优势

之前写过关于向代理式编程转变的文章。在 AI 代理执行任务的时代，以命令行界面（CLI）优先和声明式的系统才是王道。AI 代理无法可靠地在网页界面中“点击按钮”来配置 VLAN 标签或调整磁盘大小。它需要文本，需要确定性。

迁移到 NixOS 后，整个基础设施都用文本文件定义。这意味着 AI 代理可以读取、理解甚至安全地修改基础设施。Proxmox 不透明的数据库和以界面驱动的工作流程对代理来说就像一个黑匣子，而 NixOS 则是一本打开的书。如果让代理“在 9000 端口部署一个 Faster Whisper API 服务器并将其暴露到局域网”，它不需要在“服务”菜单、“网络”菜单和“防火墙”菜单中来回导航。它只需编写一个 systemd 服务定义，并在同一文件中添加 `networking.firewall.allowedTCPPorts = [ 9000 ];` 即可。代理甚至可以通过检查 git 差异或活动配置来验证更改是否成功。这就是所经历的“代理式编程”革命在基础设施方面的体现。

一位使用 NixOS 多年的朋友最近称赞配置结构非常好，尤其是在管理 8 台不同机器方面。有趣的是，配置几乎不是自己写的。是在多次会话中通过代理式 AI 完成的。对配置进行了多次重构，从管理一台机器到两台，最终扩展到九台。AI 承担了重构的繁重工作，确保 PC、NUC 和 HP 既能共享通用模块，又能保持各自的特点。

架构：Incus 与模拟

仍然希望有一种纯粹的“Nix”方式来管理持久、有状态的 LXC 容器和虚拟机。虽然有 `nixos - containers` 或 `microvm.nix` 等项目，但它们往往缺乏成熟的操作能力或实时迁移功能，不如强大的虚拟机管理程序。Incus（LXD 的社区分支）完美地填补了这个空白。它让能像管理 NixOS 主机一样管理“批量”资源，同时允许在稳定、可管理的环境中运行“特殊”的遗留工作负载（比如旧 Ubuntu 容器或 Home Assistant 虚拟机）。关键是，Incus 完全可以通过简洁的命令行界面控制，使其成为代理式工作流程中的理想选择。

随着时间的推移，已经将大多数遗留的 LXC 容器（如 DNS 或媒体管理服务）迁移到了在虚拟机内运行的声明式 Docker Compose 文件中。但还有一个主要的难题：Home Assistant OS。一直没有找到合适的替代方案。原以为需要像 Proxmox 这样的专用设备操作系统才能可靠地运行它。后来才发现，在 NixOS 上使用 Incus 运行 Home Assistant 的完整虚拟机非常简单。它只是另一个 QEMU 进程，但管理起来和容器一样轻松。

做的一件很巧妙的事是创建了与物理机器配置完全相同的 Incus 虚拟机。在关闭最后一台 Proxmox 主机之前，就确信整个配置是可行的，因为有一台运行相同设置的虚拟机。只需要一个包含覆盖配置的小文件，然后就可以验证虚拟机是否正常工作。这消除了对“彻底更换”物理服务器的担忧。

迁移过程

由于有 `vzdump` 和 `qemu - img`，迁移过程出人意料地简单。以下是如何在不丢失数据的情况下迁移 7 年多的数字历史的方法。

还在 dotfiles 中保留了一些详细的迁移笔记。这些笔记应该足以帮助任何想进行相同迁移的人。如果不够，把它们交给 AI（用的是 Gemini 3 Pro）肯定能帮解决问题。

1. 迁移 LXC 容器

对于 LXC 容器（运行 Docker、DNS 等），基本上是“瞬移”它们。将 Proxmox 上运行的容器导出为标准的 tar 包，复制到新环境，然后直接流式传输到一个全新的 Incus 容器中。

在 Proxmox 上：

# 将容器 101 导出到压缩存档
vzdump 101 --dumpdir /var/lib/vz/dump --mode suspend --compress zstd

在 NixOS 上（使用 `migrate - lxc.sh` 脚本）：

# 将备份流式传输到新的 Incus 容器
./migrate - lxc.sh vzdump - lxc - 101 - *.tar.zst ubuntu - container

这个脚本会创建一个新容器，挂载其根文件系统，并用 Proxmox 的导出文件覆盖它。它会自动处理一些繁琐的事情，比如映射用户 ID 和修复 `machine - id`。

2. 迁移虚拟机

对于虚拟机（如 Home Assistant OS），只需要转换磁盘格式。Proxmox 使用 LVM - thin 或 ZFS zvols，而 Incus 支持 QCOW2 或原始 ZFS。

在 Proxmox 上：

# 将 ZFS 卷导出为 QCOW2 文件
qemu - img convert - p - O qcow2 /dev/zvol/rpool/data/vm - 100 - disk - 0 vm - 100.qcow2

在 NixOS 上（使用 `migrate - vm.sh`）：

# 导入磁盘并创建虚拟机
./migrate - vm.sh vm - 100.qcow2 home - assistant

迁移结果

现在，可以从一个单一的 git 仓库管理整个设备群，包括主机操作系统、网络、存储和虚拟机管理程序配置。实现了两全其美：在需要的地方运行持久、有状态的服务，同时拥有一个可重现、坚如磐石的主机操作系统。可以擦除主机，重新安装 NixOS，运行恢复脚本，几分钟内就能恢复在线。最棒的是，再也不用记住三年前在网页界面中点击了哪个复选框。一切都在代码里，而且因为是代码，代理可以帮管理。

相关文章

- 使用本地缓存服务器自动化 NixOS 夜间构建以避免本地编译

- 无需云服务的 TrueNAS 朋友间备份

- 家庭实验室：从单个树莓派到 Proxmox 集群和专用 NAS 🔧

- 用手机编程 📱

- 3090 显卡如何演变成两个本地优先的 AI 项目 🎮