从 Proxmox 到 NixOS + Incus：我的全声明式基础设施迁移之旅

背景

作者长期在家庭实验室（Homelab）中使用 Proxmox VE 作为虚拟化平台，从最初的单台 Intel NUC 扩展至多节点集群。然而，随着对系统可复现性、自动化运维以及 AI 智能体（AI Agents）集成需求的提升，作者决定彻底弃用 Proxmox，将全部基础设施迁移至基于 NixOS 的系统，并使用 Incus 作为容器和虚拟机管理程序。

这一转变并非一蹴而就。作者最初对 Nix 语言及其语法持怀疑甚至厌恶态度，更倾向于使用 Dotbot 和自研工具管理 dotfiles。真正的转折点发生在作者组装游戏 PC 并遭遇 NVIDIA 驱动地狱（Driver Hell）之后。在尝试修复驱动问题导致 GRUB 启动循环后，NixOS 的原子更新（Atomic Updates）和声明式配置特性解决了这一痛点，使作者深刻体会到“配置即代码”的价值，从而完成了从怀疑者到坚定拥护者的转变。

核心内容

从 GUI 优先到声明式文本的范式转移

Proxmox 是一款优秀的软件，它降低了虚拟化、LXC 容器和 ZFS 的学习门槛，但其核心范式是“点击按钮”的 GUI 优先模式。虽然可以通过 Terraform 或 Ansible 进行自动化，但往往感觉像是在与工具对抗。这种基于 GUI 的管理方式会导致严重的“状态漂移”（State Drift）：管理员可能在 UI 中修改设置以调试问题，随后遗忘该操作，导致数月后“基础设施即代码”与实际运行状态不同步。

对于人类管理员而言，这仅是烦恼；但对于 AI 智能体而言，这是灾难。当 AI 以“YOLO 模式”（盲目执行）运行数百条命令来修复问题时，虽然可能暂时成功，但会将系统置于未定义且不可复现的状态，连 AI 本身也无法准确理解或复制后续状态。

相比之下，NixOS 将所有基础设施定义为文本文件。这种声明式方法不仅消除了状态漂移，还为 AI 智能体提供了理想的交互界面。AI 无法可靠地在 Web 界面中“点击按钮”来配置 VLAN 或调整磁盘大小，它需要的是确定性的文本输入。在 NixOS 中，AI 可以读取、理解并安全地修改基础设施配置。例如，若要求 AI “在 9000 端口部署 Faster Whisper API 服务器并暴露给局域网”，AI 只需编写 systemd 服务定义并添加 networking.firewall.allowedTCPPorts = [ 9000 ];，而无需在复杂的菜单中导航。AI 甚至可以通过检查 git diff 或活动配置来验证更改是否成功。

硬件管理与故障复现的确定性

声明式配置在硬件故障处理上展现了巨大优势。作者以 HP EliteDesk 上的 Intel I219-LM 网卡为例，该网卡在启用硬件卸载时存在已知 bug，会导致网络随机断开。在 Proxmox 时代，作者多年前曾通过命令行修复此问题，但细节已遗忘。在 NixOS 中，修复方案被记录为一个带有详细注释的 systemd 服务，解释了为何需要关闭 TSO 和 GSO。如果重新安装机器，修复会自动应用，无需重新发现痛苦。

另一个例子是 Intel NUC 的多用途利用。由于家庭实验室位于电视后方，作者希望将其兼作家庭影院 PC（HTPC）。在 Proxmox 中，这需要 GPU 直通给虚拟机，导致宿主机完全失去 GPU 访问权限，一旦出错便无法本地调试，形成“媒体播放器”与“可调试宿主机”的二选一困境。而在 NixOS 中，作者直接在宿主机上运行 Kodi 以获得原生硬件加速和视频输出，同时后台运行 Incus 托管容器。这种架构无需虚拟化开销，也无需面对“无头宿主机”的限制，实现了 HTPC 与服务器在同一硬件上的完美共存。

哲学差异： Appliances vs. 完全掌控

Proxmox 和 TrueNAS 等系统被设计为“电器”（Appliances），用户不应在宿主机上运行任意命令或安装软件，以免破坏中间件或在升级中丢失更改。这实际上限制了用户对硬件潜力的完全掌控。NixOS 则相反，宿主机完全属于用户。用户可以随意安装 Kodi、调整网络驱动或运行本地 LLM，因为状态是声明式的，任何配置错误都可以在几秒钟内恢复，即使机器正在运行关键服务。

架构选择：Incus 与模拟

尽管希望有纯粹的“Nix”方式来管理持久化、有状态的 LXC 容器和虚拟机，但像 nixos-containers 或 microvm.nix 等项目在操作成熟度或实时迁移功能上尚不及成熟的 Hypervisor。Incus（LXD 的社区分支）完美填补了这一空白。它为 NixOS 宿主机提供了“牲畜”（Cattle，指可批量替换、无状态管理）式的管理体验，同时允许在稳定环境中运行“宠物”（Pet，指需单独呵护、有状态）式遗留工作负载（如旧的 Ubuntu 容器或 Home Assistant VM）。

Incus 完全通过干净的 CLI 控制，使其成为 AI 智能体工作流的完美公民。作者已将大多数遗留 LXC 容器迁移到在 VM 中运行的声明式 Docker Compose 文件，但对于 Home Assistant OS，起初认为需要专用的电器 OS。后来发现，在 NixOS 上使用 Incus 运行完整的 Home Assistant VM 非常简单，它本质上只是另一个 QEMU 进程，但管理难度与容器无异。

AI 驱动的自动化重构

作者提到，其朋友称赞其配置结构清晰，尤其是管理 8 台不同机器时。有趣的是，作者几乎未亲手编写配置代码，而是通过多次会话利用 AI 智能体完成。AI 承担了重构的重任，确保 PC、NUC 和 HP 机器共享通用模块，同时保留各自的独特性。这种“代理式编码”（Agentic Coding）革命的基础设施对应物，正是声明式文本文件。

关键要点

• 声明式优于命令式：NixOS 的声明式配置消除了 GUI 管理带来的状态漂移，确保系统状态始终可复现、可审计。
• AI 智能体的最佳搭档：AI 智能体擅长处理文本和确定性指令，而非操作 Web UI。NixOS 的文本配置文件使 AI 能够安全、高效地部署服务、修改网络配置并验证结果。
• 硬件故障的持久化修复：将硬件特定的修复措施（如网卡驱动参数调整）固化为配置代码，避免了重复的手动调试和记忆丢失。
• 打破宿主机与应用的隔离：NixOS 允许在宿主机上直接运行图形应用（如 Kodi），同时运行虚拟化服务（Incus），无需像 Proxmox 那样在 GPU 直通和宿主机调试之间做艰难取舍。
• Incus 填补生态空白：在 NixOS 生态中，Incus 作为成熟的 Hypervisor，提供了比纯 Nix 容器方案更强大的生命周期管理、实时迁移和遗留系统支持能力。
• AI 辅助的基础设施重构：利用 AI 智能体进行大规模配置文件的编写、重构和模块化，可以显著降低多节点异构硬件的管理复杂度。

意义与影响

这篇迁移记录不仅是一个个人技术博客，更反映了基础设施管理领域的一个深层趋势：从“运维”向“工程”的回归，以及 AI 原生基础设施的兴起。

1. AI 原生基础设施的必要性：随着 AI 智能体逐渐介入 DevOps 和运维流程，传统的 GUI 驱动或半自动化系统将成为瓶颈。只有具备高度确定性、文本化、声明式接口的系统（如 NixOS + CLI 工具）才能与 AI 智能体形成良性互动，实现真正的自主运维。
2. 对“电器化”操作系统的反思：Proxmox、TrueNAS 等“电器化”系统虽然易用，但牺牲了灵活性和可审计性。在追求极致效率和可复现性的场景下，全掌控的通用操作系统（如 NixOS）结合专业组件（如 Incus）提供了更优的解耦方案。
3. 开发者工作流的变革：作者的经历表明，AI 不再仅仅是代码生成的助手，它可以