每隔几个月，就会有人问我：家庭实验室到底该上 Proxmox，还是干脆装个 Linux 完事？这个问题通常被包装成「Proxmox 与纯 Linux」的对决，而网上的答案又往往被讲成一场信仰之战。我认为这个框架本身就错了。**虚拟机管理器（homelab hypervisor）**是一件有特定形状的工具：它用多一层的复杂度，换来快照、生命周期管理和隔离。这笔交易值不值，完全取决于你在上面跑什么，而不是你加入了哪个阵营。
两种我都跑过。我跑过一台挂着一堆 guest 的 Proxmox，也把同样的负载当成普通的 systemd 服务跑在一台主机上。两边都能用，两边都不神奇。下面是不带滤镜的版本——不把虚拟化当成一种身份。
一个家庭实验室虚拟机管理器到底能买到什么
先把 Proxmox 该得的分给它，因为它的好处是真实的，而贬低它的人，往往是在为错误的目标做优化。
- 快照。 这是招牌功能。一次冒险的升级之前先打个快照，搞坏了，几秒钟回滚。在纯 Linux 上你也能做，但你得在装机时就先定好存储布局（ZFS 或 LVM-thin），并且回滚流程得自己扛。Proxmox 给你的不只是按钮，更是一个习惯。
- 轻松的虚拟机与容器生命周期。 建一台 VM 或一个 LXC 容器就是点几下。从模板克隆、设定资源、挂到网络桥——都在一处完成。在纯 Linux 上，这些要用
qemu-system、systemd-nspawn、debootstrap和你自己写的脚本拼出来。更透明，也更多手工。 - 隔离。 每个 guest 有自己的内核（虚拟机）或独立命名空间的用户态（容器）。一个被攻陷的服务不会轻易够到另一个。而在单台纯 Linux 主机上，一个坏掉的服务就挨着你的数据运行，权限完全取决于你当时怎么给的。
- 一个界面。 这个 Web 界面在处理那些枯燥环节时确实有用：SSH 挂了还能开控制台、一张粗略的资源图、一份备份计划列表、晚上十一点能点一下「启动」的地方。这些在纯 Linux 上你靠 SSH 和 systemd 也能做到，但不是收在同一个面板里。
把这些东西合在一起看，才是一个 hypervisor 存在的意义。如果你看重这一整套，它就值这个价。
纯 Linux + systemd + 容器又能给你什么
另一边并不是「什么都没有」，而是另一组完全不同的好处：
- 简单。 你和机器之间没有抽象层。
systemctl status、journalctl -u、ss -ltnp，你就什么都清楚了。没有集群文件系统的怪毛病，没有要装的 guest agent，也没有「为什么 Web 界面显示的磁盘不对」。 - 没有额外的一层。 每个 guest 都要为自己的用户态吃掉 CPU 和内存。在一台小家庭实验室机器上，这份开销占预算里相当可观的一块。纯 Linux 只有一个内核。
- 直接访问。 挂载存储、改内核参数、临时丢个调试二进制进去、在物理网卡上跑
tcpdump——全都是立刻生效。而在 hypervisor 上，你偶尔得先问「这是宿主机的问题还是 guest 的问题」，而这个问题是要花时间的。 - 更小的补丁面。 每周只更新一个系统，而不是一个宿主机加上 N 个 guest。工作量不是零，但更少。
这和我在不用 Docker 的自托管里给出的论证是同一条：对于少数稳定的服务来说，操作系统本身就是那个编排器，在它上面再加一层控制面，往往是一笔再也收不回来的税。
Proxmox 的真实代价
这是吹捧会跳过的部分。Proxmox 并不免费，它的代价是：
- 又多了一个要打补丁的东西。 它是一个基于 Debian 的发行版，有自己的软件包、自己的内核、自己的 Web 技术栈。这等于在每个 guest 的更新节奏之外，再加一条更新节奏。一旦你跳过它，局域网里就多了一个没打补丁、还开着监听的管理界面。
- ZFS 的内存胃口。 常见建议是给 ARC 留一块内存，而 ZFS 去重是个陷阱，会吃掉你本该留给实际 guest 的内存。在一台内存不宽裕的机器上，选那个「看起来更高级」的文件系统，其实是在悄悄少跑一个 guest。这是真实的工程取舍，不是免费升级。
- 仍然要自己配置的备份。 快照按钮不是备份。快照和你保护的东西睡在同一个池子里，一块盘坏了，两个一起没。你依然得配一个真正的备份任务，最好落到另一台设备上，并且验证它确实能恢复。Proxmox 让这件事更省事，而不是自动完成。我在能够恢复的备份里那条规则依旧成立：没验证过的备份是希望，不是备份。
- 把所有东西都虚拟化的倾向。 一旦有了 hypervisor，每件小事都会变成一个 guest。一个小小的定时任务要开个容器，一个静态站点要开台虚拟机。最后你维护着十个迷你操作系统，明明一个就够；而机器把资源花在了那一层上，而不是花在真正的工作上。
最后一条是最隐蔽的代价，它是文化层面的，而非技术层面的。
Proxmox 与纯 Linux：一张决策表
我实际就是这样做决定的。找到和你情况相符的那一行。
| 你的情况 | Proxmox | 纯 Linux + systemd + 容器 |
|---|---|---|
| 很多你爱折腾、经常搞坏的服务 | 更好：快照、回滚、再来一次 | 痛苦：你得手工重建 |
| 少数几个稳定的服务 | 过于重：你为一个用不上的层付费 | 更好：单内核、直接控制 |
| 想学 hypervisor／搭实验环境 | 更好：这正是目的 | 不是目标 |
| 小机器、内存紧张 | 有风险：ZFS + 每个 guest 的开销 | 更好：一点都不浪费 |
| 需要在多租户之间强隔离 | 更好：VM 之间内核独立 | 较弱：容器共享内核 |
| 讨厌多出来的补丁通道 | 更糟：宿主机加上每个 guest | 更好：一个系统要更新 |
| Windows 与 Linux 混合负载 | 更好：VM 是天然归宿 | 别扭 |
| 一个博客、几个 API、一些定时器 | 过于重 | 更好 |
如果你的大多数行都落在同一侧，决定其实已经做完了。真正的陷阱，是去选那个听起来更专业的一栏，而不是匹配你实际工作的那一栏。
务实的中间路线
你不必在「裸机上毫无隔离」和「一套完整的 hypervisor」之间二选一。中间路线是一台纯 Linux 宿主机，用系统自带的工具，仍然拿到大家真正想要的大部分虚拟化能力。
对于系统容器——也就是 LXC 那一类场景——你有内建于 systemd 的 systemd-nspawn。它给你一个拥有独立文件系统与进程命名空间的容器，像普通单元一样被启动和守护：
# /etc/systemd/nspawn/notes.nspawn
[Exec]
Boot=on
PrivateUsers=pick
[Network]
Private=yes
VirtualEthernet=yes# 用 debootstrap 造一个 Debian 容器，然后运行它
sudo debootstrap --include=systemd,iproute2 stable /var/lib/machines/notes \
http://deb.debian.org/debian
sudo systemctl start systemd-nspawn@notes
sudo machinectl shell notes # 像进 VM 控制台一样进去对于应用容器，podman 无需守护进程就能跑 OCI 镜像，配合 rootless 模式，它是一条相当合理的单服务隔离边界：
podman run -d --name wiki --restart=always \
-p 127.0.0.1:8080:8080 \
-v /srv/wiki/data:/data:Z \
docker.io/requarks/wiki:2
podman generate systemd --new --files --name wiki # 交给 systemd 守护快照和备份也不需要 hypervisor。如果你的根池是 ZFS，zfs snapshot 加 zfs send | zfs receive 就能给你原子、可验证的副本。如果不是，restic 或 borg 备份到另一台机器，同样能做到去重和加密。
所以中间路线就是：一台宿主机，需要独立用户态的东西交给 systemd-nspawn，第三方镜像交给 podman，再配一个你真正恢复过的备份任务。该要隔离和轻松回滚的服务得到它们，不需要的服务则不背那份额外开销。
这也正是我自托管的那些东西的跑法：少数几个无聊的服务，直接由 systemd 守护，备份是验证过的，而不是想当然的。
虚拟化是工具，不是人设
诚实的总结：当你要跑很多东西、经常把它们搞坏、又希望生命周期和快照机制收在一处时，用 Proxmox。当你只有少数几个稳定服务，并且比起一个控制面板更看重直接访问和更小的补丁面时，用纯 Linux。
两种选择都不会让你变成更厉害的工程师。那个为了显得认真而把一切虚拟化的人，和那个为了原则而拒绝任何抽象的人，错得一样多。把工具对上工作，让备份保持真实，别为了一个你根本不存在的难题，去加一台 hypervisor。