先说一个我这两年反复遇到的典型部署场景（为便于说明，以下为假设案例，非真实客户）：某公司在机房租了三台双路物理机，配置不算差，每台 32 核、256G 内存、两块 NVMe 做系统盘加四块 SATA 做数据盘。动机很朴素——业务上有十几个内部系统，直接租云主机一年下来觉得不划算，干脆自己拿三台机器搭个虚拟化池子，把十几个 VM 塞进去，还能随时迁移。
他们选了 oVirt，装的时候很顺利：Engine 装在第一台机器的虚拟机里，三台 Host 全部纳管，创建了 VM，跑了小半年。直到某天凌晨其中一台 Host 主板挂了，令人意外的事发生了——那台机器上跑着的六个 VM，一个都没能在另外两台机器上自动拉起来，全部卡在 "Unknown" 状态，需要人工在管理界面里点"确认主机已重启"才能手动启动，而确认之前谁也不敢启动，怕两边同时写同一块盘。
问题出在哪？不是 oVirt 的 bug，是这套架构从一开始就缺了三个东西：没有共享存储（每台机器用的是自己的本地盘，VM 磁盘根本没被别的节点看见）、没有配电源管理（fence）（Engine 无法确认那台机器是真死了还是只是管理网络断了，因此不敢擅自重启 VM）、没有理解数据中心和集群的层级（Engine 的 PostgreSQL 数据库就跑在它所管理的其中一台 Host 上，Host 一死，管理端自己也瘫了）。
这三个坑，恰好对应自建虚拟化最容易翻车的三块：存储域、高可用、以及层级模型。这篇不打算把 oVirt 吹成"企业级私有云的平替"，我想讲的是——什么时候值得自建，什么时候这笔账根本算不过来，以及真要自建，哪些地方必须一次做对。
很多人把 oVirt 理解成"一个能管一堆 KVM 机器的控制面板"，这个理解不算错，但太粗，粗到出问题时你不知道该去哪台机器的哪个日志里找。
准确的分层是这样的：最底层是 Linux 内核的 KVM 模块，负责 CPU 与内存的虚拟化；往上是 QEMU，负责设备模拟（网卡、磁盘控制器、显卡、USB 等）与进程生命周期；再往上是 libvirt，它提供一套统一的 XML 描述与 API，把"定义一个虚拟机""启动/迁移/销毁""管理网络与存储池"这些动作抽象出来，屏蔽掉 QEMU 命令行细节；最上层才是 VDSM（Virtual Desktop and Server Manager），这是 oVirt 部署在每个节点上的代理程序，它接收 Engine 下发的指令，翻译成 libvirt 的调用，同时把节点状态、VM 状态、存储域心跳这些信息持续上报给 Engine。
而 oVirt Engine 本身是一个 Java Web 应用，跑在 PostgreSQL 上，它自己不直接碰任何一台 Host 的 libvirt，所有操作都通过 VDSM 中转。这个设计的直接后果有两个，都是必须在动手前就接受的：
第一，Engine 是单点。它挂了不影响正在运行的 VM（VM 由各节点的 libvirt/QEMU 进程维持，不会因为管理端掉线就关机），但你在这期间无法迁移、无法开机、无法改配置、无法看到准确状态。所以 Engine 的备份优先级高于任何一台 VM——因为它存着整个集群的元数据：哪些 VM 在哪台 Host、磁盘挂在哪个存储域、MAC 地址分配、网络绑定关系。Engine 的数据库损坏比丢一台 VM 严重得多。
第二，Engine 不应该跑在它所管理的 Host 上。这是上文那个假设案例里最致命的一条，也是新手最常犯的。Engine 装在受管 Host 的 VM 里，等于把大脑放在了它要管理的身体里面——那台 Host 一挂，大脑跟着没了，剩下的节点没人指挥，HA 自然无从谈起。正确做法是：Engine 独立部署在一台单独的物理机、或者干脆部署在不受此集群管理的另一套环境/云主机上，通过管理网络访问各节点。
节点失联时 Engine 的判断逻辑也值得说清楚，因为它决定了你的 HA 行为是否符合直觉。Engine 通过 VDSM 的心跳判断 Host 存活，心跳超时后不会立刻重启 VM，而是先尝试通过配置的电源管理设备（IPMI、iDRAC、iLO、或者带 SNMP 的 PDU）去隔离（fence）这台主机——通常是强制断电或重启。只有 fence 操作明确返回成功，Engine 才会认定"该主机上的 VM 已经确定停止"，进而在别的节点上把它们拉起来。如果 fence 失败，Engine 会一直等、一直重试，VM 就一直卡在那个 Unknown 状态。这不是设计缺陷，是刻意的安全保守：在没有证据证明原主机已经停止写磁盘之前就启动同一块盘的第二个写入者，结局只会是文件系统损坏。
oVirt 的层级模型是：数据中心（Data Center）→ 集群（Cluster）→ 主机（Host）与虚拟机（VM），而存储域（Storage Domain）与逻辑网络（Logical Network）是挂在数据中心这一层的资源，再由集群去引用。这个关系搞反，是配置错乱的根源。
具体来说，存储域必须先关联（Attach）到数据中心并激活，集群里的主机才能通过数据中心访问它。很多人建了第二个集群，发现"新集群的机器看不到原来那个存储域"，原因就是存储域只挂在了旧的数据中心上——而他们误以为存储域是挂在集群上的。同理，逻辑网络是在数据中心层面定义的，再分配到集群中的每个主机网卡上；你在 A 集群配好的 VLAN 网络，B 集群的机器不会自动拥有，需要在 B 集群里再做一次"网络附加到主机接口"的操作，并且物理网卡的名称、绑定模式还要对得上。
集群的真正语义是一组 CPU 型号兼容、可以互相在线迁移的主机集合。同一集群内，因为要支持在线迁移，CPU 特性集必须取交集——oVirt 提供 "CPU Type" 设置（如 Intel 的某个通用 family 级别），把不同代际 CPU 的特性统一到一个较低水平，代价是牺牲掉新 CPU 的部分指令集。这也是为什么有人把不同代际的机器塞进一个集群后，发现"迁移过去了但应用性能掉了"或者"某些软件报非法指令"。
数据中心的语义则是管理与资源的边界：存储域、逻辑网络、配额（Quota）、MAC 地址池都在这一层。一个数据中心可以包含多个集群，这些集群共享同一批存储域和网络定义。所以正确的划分思路是：按"是否需要共享同一批存储和网络"来划数据中心，按"CPU 代际与迁移需求"来划集群。举个例子，你有一批老 E5 机器和一批新 Xeon 可扩展机器，它们共用同一套共享存储，那么应该是一个数据中心 + 两个集群，而不是两个数据中心，也不是一个集群。
oVirt 里还有一种特殊类型叫本地数据中心，它只能包含一个集群、且该集群只能有一台主机。这是给单机测试或纯本地盘场景准备的。一旦你选了它，就等于放弃了在线迁移和 HA——这是设计如此，不是 bug。有些教程让人用它来"简化配置"，等你后面想加机器时才发现整个数据中心要重建，很折腾。
存储域是 oVirt 里最容易被低估的概念。它不是简单的"一个挂载点"，oVirt 会在其上维护自己的元数据（存储域描述、磁盘卷的元数据、以及用于防脑裂的 lease 区域）。理解这一点，才能理解为什么有些操作（删除存储域、扩容、恢复）那么麻烦。
核心结论先摆出来：只要 VM 的磁盘不在共享存储上，在线迁移和 HA 就都不成立。这不是 oVirt 的限制，是所有虚拟化平台的共同前提——在线迁移可以搬内存状态和 CPU 状态，但搬不动几十上百 GB 的本地磁盘数据（除非做存储迁移，但那也需要目标端有存储域）。
NFS 域把 VM 磁盘以文件（qcow2 或 raw）形式存在 NFS 导出目录里。优点是部署简单、可见可复制、排障直观（你能直接 ls 到磁盘文件）。oVirt 支持 NFS v3、v4、v4.1、v4.2，具体版本支持与推荐配置以官方安装与管理指南为准。它最大的隐性风险是：NFS 服务端成了新的单点。你花三台机器消灭了计算层的单点，却把整个集群的磁盘 IO 押在了一台 NFS 服务器（或一套 NAS）上。要给这套 NFS 做双控、做 RAID、做网卡绑定、做 UPS，成本要算进去。NFS 的锁语义、export 权限（oVirt 对目录属主有要求，通常要 vdsm 用户可写）、以及防火墙端口，是部署阶段最常见的三类报错来源。
块存储域的做法是：把一个 LUN 交给 oVirt，oVirt 在这个 LUN 上创建 LVM 卷组，每块 VM 磁盘是一个逻辑卷（LV）。好处是性能更接近裸设备、无文件系统层叠加、快照与克隆走 LVM 机制。代价是运维复杂度明显抬升——你要管 iSCSI initiator、多路径（multipath）、CHAP 认证、LUN 掩码，还要理解"存储域元数据也占着这个卷组里的区域"。块存储域有一类经典故障：卷组空间看还剩很多，但创建磁盘失败，通常是元数据区或 LVM 的 extent 分配策略问题；另一类是 LUN 被意外共享给了两台不该共享的机器，导致元数据被并发写坏，这种损坏基本不可修。所以块存储域的 LUN 掩码必须在存储侧严格配置，不能偷懒。
本地存储域挂在单台主机的本地磁盘上，VM 只能跑在这一台机器上，不能迁移、不能 HA、不能存储迁移。它的定位非常明确：跑无状态的、或者能容忍停机的负载——比如内部的一个测试环境、一个开发用的构建机、一个临时的日志收集节点。把它用在生产数据库上，就是把可用性押在单台机器的主板上。上文假设案例里那家公司的错误，就是拿本地盘搭了一个"看起来有 HA"的集群。
Gluster 曾被作为 oVirt 超融合（Hyperconverged）的推荐方案，通过副本卷把三台机器的本地盘凑成一个共享存储域。思路很诱人：不用额外买存储设备。但这条路的实际坑不少——仲裁/脑裂（三副本下网络分区后谁是权威）、副本修复期间的 IO 延迟抖动、小文件与元数据性能偏弱、扩容与换盘流程复杂，加上社区支持与版本配套关系发生过变化，具体到某个 oVirt 版本是否还支持 Gluster 域、支持到什么程度，务必以官方文档与版本支持说明为准，不要照搬三年前的教程。我的建议偏保守：内部业务、数据量不大、能接受停机窗口的，可以考虑用成熟的商业/开源 SAN 或独立 NFS 服务器；没有专职存储的团队，直接把 VM 放在本地盘 + 做好备份，往往比硬上超融合更稳。
| 对比维度 | NFS 文件存储域 | iSCSI / FC 块存储域 | 本地存储域（Local on Host） | GlusterFS 超融合 | 什么时候该选它 |
|---|---|---|---|---|---|
| 是否支持 VM 在线迁移 | 支持 | 支持 | 不支持，VM 被钉死在该主机 | 支持（前提：副本卷健康、无分区） | 只要有任何一台 VM 需要热迁，前两种里选 |
| 是否支持 VM 高可用（HA） | 支持，需配 fence 与 lease | 支持，且 lease 机制成熟 | 不支持，主机宕机 VM 一起没 | 支持，但分区时行为需重点验证 | 生产业务只有共享存储这一条路 |
| 部署与长期维护复杂度 | 低，目录可见、排障直观 | 高，涉及 LUN、多路径、LVM、CHAP | 最低，几乎零配置 | 高，且排障需要专项经验 | 团队没有存储运维就别碰块与超融合 |
| 典型故障面 | 服务端单点、锁与权限、网络抖动导致域无响应 | LUN 误共享导致元数据损坏、多路径配置错误 | 单盘故障即数据丢失（除非做了本地 RAID 与备份） | 脑裂、副本修复期性能抖动、换盘流程复杂 | 故障面决定你要储备哪种排障能力 |
| 适合承载的负载 | 内部 OA、ERP、中间件、开发测试环境 | 数据库、对 IO 延迟敏感的核心系统 | 无状态服务、测试机、可容忍停机的边缘系统 | 预算受限且能接受性能波动的内部系统 | 按业务重要性分层放，不要一刀切 |
| 扩容方式 | 扩后端卷或新增导出目录后新建域 | 新增 LUN 并扩卷组，需严格按官方流程 | 加本地盘，但 VM 依旧绑死单机 | 加节点或加盘后做副本再平衡 | 扩容前先确认备份可用，别边扩容边赌 |
这是全篇我最想强调的一段。oVirt 界面里给 VM 开高可用，就是一个复选框。但 HA 真正生效需要三件事同时成立，缺一个就是"看起来开了 HA，实际不会自动恢复"。
每台 Host 都要在 Engine 里配置电源管理设备——服务器带外管理口（IPMI / iDRAC / iLO）最常见，也可以是有 SNMP 控制的 PDU。配置完必须点"测试"确认 Engine 能真的执行开机、关机、重启，并正确读回电源状态。这一步很多人跳过了，结果就是：主机宕机 → Engine 判定失联 → 尝试 fence → 失败 → 无限重试 → VM 永久卡在 Unknown。你在监控上看到的不是"VM 自动恢复了"，而是"管理界面上多了一堆需要人工确认的问号"。
讲清楚这个机制，你就不会再想省掉 fence。假设 A 主机上跑着一个 VM，它的磁盘在共享存储上。某时刻 A 与存储之间的网络断了（注意：A 主机本身没死，QEMU 进程还在跑，还在往共享磁盘里写数据），但 A 与管理网络还通或者也不通。
如果 Engine 因为心跳超时就判定 A 已死，并在 B 主机上启动同一个 VM —— 那么此刻，同一块虚拟磁盘同时被 A 上的旧 QEMU 进程和 B 上的新 QEMU 进程打开写入。两个操作系统实例各自认为自己独占这块盘，各自刷自己的 page cache、各自更新文件系统元数据、各自的数据库在写自己的 redo。几秒钟的双写就足以让 ext4/xfs 的元数据与 journal 互相覆盖，轻则 fsck 后丢文件，重则整个文件系统挂载不上，数据库直接报废。这就是脑裂双写，也是所有集群软件对"隔离"这件事如此执着的原因。
fence 的意义就在于：在启动备用实例之前，先用带外通道把原主机打死并确认它已经死了。带外管理口走的是独立于业务网和管理网的第三张网络（或至少独立网口），即使主机操作系统卡死、网络栈不通，BMC 仍能响应断电指令。只有 fence 返回成功，才获得了"原写入者已停止"的证据。所以 oVirt 的保守不是缺陷，是保护你的数据。
fence 解决的是"原主机被打死"，但还有一个更隐蔽的场景：主机确实死了，但它是"假死"——比如管理网短暂抖动，Engine 与它失去联系，fence 把它重启了，重启后它又活过来，此时如果它上面的 VM 已经在别的节点跑起来了，就又回到双写。oVirt 用两套机制覆盖：一是主机级别的仲裁（通过 vdsm 在存储域上维护的 host lease / 集群的 SAN 锁，少数派的主机不能启动受保护的 VM）；二是 VM 级别的 vm lease（storage lease）——为 VM 在存储域上分配一个租约区域，VM 启动时必须持有该租约，拿到租约才能启动。这样即使 Engine 判断失误，第二个实例也会因为拿不到租约而启动失败，磁盘不会被双写。
实践建议：生产 VM 一律勾选启用 lease，并且务必确认你的存储域类型支持 lease（块存储域与较新的 NFS 版本支持情况以官方文档为准）。HA 的恢复也不是零中断：fence + 检测 + 在别的节点冷启动 VM，全过程通常是分钟级，VM 内部相当于一次断电重启，不是无缝切换。对真正要求秒级连续性的业务，应该在应用层做主备或集群，而不是指望 VM HA。
oVirt 安装后会默认建一个叫 ovirtmgmt 的管理网络，Engine 通过它与 VDSM 通信。很多人的第一个网络错误是：把业务流量也塞进 ovirtmgmt。后果是业务突发流量把管理通道挤爆，Engine 收不到心跳，误判主机失联，触发 fence——然后你亲眼看着"网络一忙，机器就被自己人打死"。
正确做法是物理或逻辑上分离：管理网（ovirtmgmt）单独走一个网口或一对绑定口，最好还带独立的网段与网关；业务网络用另外的物理口，以逻辑网络的形式在数据中心里定义，再按 VLAN ID 打标分配到主机接口。迁移网络也建议单独一条——在线迁移会吃满带宽，尤其是内存大、脏页率高的 VM，迁移流量跑在管理网上同样会引发误判。oVirt 允许把某个网络标记为"迁移网络"或指定某网络承担特定角色，具体角色与设置在对应版本的官方管理指南里有说明。
oVirt 默认用 Linux bridge，配置直观、与 libvirt 网络生态契合、排障工具（brctl、bridge、ip）大家都会。OVS 的优势在于流表能力、隧道封装（VXLAN/GRE）、以及与 SDN 方案（如 OpenDaylight、OVN）的集成。如果你只是做 VLAN 隔离加绑定，Linux bridge 完全够用，我不建议为了"看起来更专业"去上 OVS——它引入了额外的用户态进程、额外的流表排障成本，而且一旦 ovs-vswitchd 出问题，整个节点的网络都受影响。只有在你确实需要 OVN/OVS 提供的能力时（比如复杂的多租户网络、覆盖网络），才值得这个复杂度。
这块是自建环境里最常和机房扯皮的地方。active-backup（主备）模式不需要交换机做任何配合，两块口接同一台交换机或不同交换机都行，同一时刻只有一块在工作，切换时丢少量包。它的好处是零依赖、零协商失败风险，对管理网这种"稳定第一、带宽第二"的流量非常合适。
LACP（802.3ad）需要交换机侧显式配置聚合组，两端模式要匹配（主动/被动），并且两块口通常要求接在同一台交换机（除非交换机支持跨设备聚合）。配置对了能叠加带宽并实现负载分担，配置错了就是"看起来绑上了，实际一边口被 STP 阻塞"或者干脆整组不通。经验之谈：管理网用 active-backup，业务网如果确定要带宽叠加，先和机房确认交换机是否支持并愿意帮你配 LACP，再动手；不要假设所有机柜交换机默认开了聚合。
虚拟机的 MAC 地址是 Engine 分配并写进 vNIC 过滤规则的。如果 VM 内部伪造源 MAC（比如跑某些网络测试、或者做透明桥接），默认会被 vNIC 的 MAC 防欺骗过滤丢掉。oVirt 的逻辑网络里可以针对特定网络放宽（允许 MAC 欺骗 / 允许混杂模式），但这个口子不要随便开——开了之后同一二层里的 VM 可以互相冒充，在共享环境里就是一个横向移动通道。真有需求（比如在 VM 里跑嵌套虚拟化的软路由），就单独建一个网络、只给这台 VM 用，别在公共业务网上开全局。
虚拟化调优这块流传的"祖传参数"特别多，我按"收益确定性"排一下序。
先说CPU pinning 与 NUMA 对齐。现代双路服务器是 NUMA 架构：每颗 CPU 连同它直连的内存条构成一个 NUMA 节点，跨节点访问内存要走过 CPU 之间的互联链路，延迟更高、带宽更低。默认的 VM 调度不保证 vCPU 与内存落在同一个 NUMA 节点上，一个 16 vCPU 的 VM 很可能有一半 CPU 在一颗处理器上、内存却大部分配在另一颗上，性能凭空损失。oVirt 支持设置 NUMA 节点穿透（把 VM 的 NUMA 拓扑暴露给 Guest）与 CPU pinning（把 vCPU 绑到具体物理核）。对数据库、大内存缓存这类延迟敏感负载，这个调优的收益是明确的、可测的。代价是牺牲了调度弹性：绑死的 vCPU 不能被在线迁移时随意调度，集群资源碎片会变多，密度下降。我的做法是：只对少数几台核心 VM 做 pinning，其余保持默认，不要全集群一刀切。
再说 hugepages。它减少 TLB miss、降低页表遍历开销，对于内存非常大（几十 GB 以上）且访问模式集中的 VM 有实际收益，也是 vhost-user / DPDK 这类用户态网络方案的必要前提。但它有明确的适用边界：使用 hugepages 后这部分内存被预留、不能被换出也不能被其他用途复用；配置不当（数量不够、挂载点不对、libvirt 未启用）会导致 VM 直接起不来；对小内存 VM 收益微乎其微。所以 hugepages 属于"针对特定负载的专项优化"，不是"开一下就更快"的通用开关。是否在你的组合下有效，务必先在测试 VM 上跑基准再全量推。
还有一块更基础的：CPU 型号与特性。前面提过，集群的 CPU Type 决定迁移兼容性。如果你希望同一集群内不同代际的机器能互相迁移，就要选一个较低的特性集；如果集群内机器完全一致，可以选 "Host Passthrough" 让 Guest 看到完整指令集，性能最好，但代价是这个集群以后不能加入不同型号的机器。这是典型的"迁移灵活性 vs 峰值性能"取舍，没有标准答案，看你更怕哪一头。
虚拟磁盘的缓存模式，直接决定了"主机掉电时你的数据还在不在"。libvirt/QEMU 提供几种选择，oVirt 会把它包装成界面选项，但底层语义一定要懂。
writethrough：写操作同时落到 host page cache 与后端存储，Guest 收到写完成确认时数据已在 host 层，安全性较高，性能一般。none（配合 O_DIRECT）：绕过 host 缓存直接写后端设备，Guest 的写直达存储，性能取决于后端，安全性取决于后端是否有掉电保护（RAID 卡的 BBU/超级电容、SSD 的掉电保护电容）。writeback：写入 host page cache 即向 Guest 返回完成，性能最好，但主机掉电时未刷盘的写会丢，且如果 Guest 内部没有正确下发 flush 指令，文件系统可能损坏。
我给生产 VM 的建议很明确：要么 writethrough，要么 none，不要为了跑分好看上 writeback，除非你的后端存储有可靠的掉电保护、有 UPS、并且你清楚 Guest 的 flush 行为。数据库类负载尤其要注意——很多"虚拟机上跑 MySQL 崩了"的事故，追到底都是缓存模式加掉电的组合拳。
qcow2 与 raw 的差异也要讲清楚。qcow2 支持精简置备（用多少占多少）、支持内部快照、支持压缩与加密，是 oVirt 常用的默认格式；代价是有一层映射与元数据开销，且快照链变长后 IO 路径变长、性能下降。raw 结构简单、IO 路径短、性能更接近裸设备，且在做底层恢复、挂载到宿主机上救数据时更直接；代价是没有精简置备（预分配就是实打实占掉）和不支持内部快照。选择依据其实很朴素：开发测试、需要频繁快照回滚的用 qcow2；核心数据库、对延迟敏感的用 raw 并配好外部备份方案。另外磁盘格式与存储域类型、磁盘置备方式（精简/预分配）的组合会影响可用功能，具体支持矩阵以官方文档为准。
还有一个容易被忽略的点：Guest 内部的 IO 调度与驱动。 VirtIO 是半虚拟化驱动，性能显著优于模拟的 IDE/e1000，磁盘用 virtio-blk 或 virtio-scsi、网卡用 virtio-net 是标配。Windows Guest 必须安装 virtio 驱动（否则连磁盘都认不到），Linux 内核通常自带。virtioscsi 相比 virtio-blk 支持更多队列与设备数，对多盘、高并发场景更友好。这些不是"调优"，是及格线。
把快照当备份用，是虚拟化环境里最普遍的误会。oVirt 的快照（尤其是 qcow2 内部快照）记录的是"从某个时间点起的增量"，原始盘变成只读底座，新写入落在增量文件里。它解决的是"我要装个补丁，崩了能滚回去"，不是"机房着火了我还有数据"。
快照常驻会带来三个问题：一是性能，读操作可能要穿透多层增量文件，链越长越慢；二是空间，增量文件会持续增长，占满存储域后 VM 会被自动暂停，这是很常见的生产事故；三是合并风险，删除快照时的 commit 操作要合并大量数据，过程中 IO 压力陡增，且一旦中断可能留下不一致的镜像。所以快照的正确用法是"用完即删"，保留时间以天计，不做长期留存。
真正的备份要分三层来做：
第一层，也是优先级最高的：Engine 的配置与 PostgreSQL 数据库。 前文说过，Engine 存着整个集群的元数据。oVirt 提供 engine-backup 之类的工具可以把数据库与配置文件一起打包，这个备份要定期做、异地存、并且定期做恢复演练——我见过太多"备份一直在跑，真要恢复时发现脚本几个月前就报错了"的情况。恢复演练的频率可以低，但不能是零次。
第二层：VM 的完整备份。 oVirt 有导出域（Export Domain）的概念，本质是一块 NFS 存储域，用来以 OVA 形式导入导出 VM 与模板。它适合做"跨环境搬运"和"冷归档"，但定位不是企业级备份系统——增量、调度、保留策略、应用一致性这些能力有限。更稳妥的做法是走 oVirt 的备份 API（增量备份相关的 REST API，各版本支持程度以官方说明为准）对接专业备份软件，或者在 Guest 内部用常规备份工具（数据库用 mysqldump/xtrabackup/pg_dump，文件用 rsync/restic 之类）。Guest 内备份是最容易被忽视但最可靠的一层，因为它不依赖虚拟化层、可恢复到任何平台。
第三层：恢复顺序的预案。 真出事时你应该清楚顺序：先恢复 Engine（否则你连"哪台 VM 在哪个盘"都不知道），再挂载存储域，再恢复 VM 注册关系，最后恢复数据。这个顺序要在纸上演练过一次，不要等到机房断电那天才开始想。
现在算账。自建虚拟化有个最小规模门槛，低于这个门槛就是给自己找事。
机器数量：如果只是两台，我不建议自建集群——两台做 HA 需要仲裁，而双节点 + 存储的仲裁配置是出了名的麻烦，且任一节点故障后剩余资源往往不足以承接全部负载（每台都跑到了 50% 以上就没法接管）。合理的起步是三台计算节点 + 一台独立存储（或一套双控存储）+ 一台独立的 Engine 机器。也就是说，想正经跑 HA，物理机数量基本是 4 到 5 台起。你要是只有两三台机器，真心不如直接租云主机或者裸金属，把可用性交给机房和平台。
网络条件：自建共享存储意味着你需要一条稳定的存储网络。iSCSI 对延迟和丢包非常敏感，存储流量和业务流量挤在一个千兆口上，迟早出事。理想配置是节点至少万兆（或双千兆绑定）用于存储，并且与业务网、管理网隔离。这就牵扯到机柜内交换机的端口数量、是否支持万兆、是否需要单独拉线——这些在租机器之前就要和机房确认清楚，事后加端口往往要挪机、要停机。
运维人力：这是最容易被漏算的一项。自建虚拟化意味着你要自己负责：内核与 oVirt 版本升级、Engine 数据库维护、存储域健康巡检、fence 设备可用性测试、证书过期、备份恢复演练、以及凌晨三点主机宕机时的处置。这个工作量大约需要一个能独当一面的 Linux 运维长期兼着，或者两三个人分摊。如果这个团队不存在，自建的隐性成本会远超你省下的那部分机器钱。
许可证：oVirt 本身是开源项目，不需要按 CPU 或按 VM 付费，这是它相对商业虚拟化最大的吸引力。但"免费"不等于"零成本"——你需要自担维护责任，没有原厂工单可开。社区邮件列表、官方wiki、文档是你的主要依靠，遇到底层 bug 时排障周期不可预期。oVirt 与上游项目的版本关系、以及对应发行版的支持情况会随时间变化，具体支持状态请以官方公告与文档为准，不要基于几年前的信息做长期规划。
反过来，什么情况下直接租云主机更划算？我给的判断标准是：VM 数量少于 10 台、没有专职运维、业务形态不固定（可能扩也可能缩）、或者需要跨地域部署，这几条命中任意一条，租比自建省心。云主机按小时/按月付费，随时升降配，机房、网络、电力、硬件故障都是别人的事。自建的优势在于：VM 数量多且稳定时单位成本低、数据不出自有物理机（合规与审计上好解释）、资源可深度定制（GPU 直通、特殊内核、大内存机型）、以及长期持有时的折旧优势。
把 oVirt 放进更大的坐标系里看，边界才清楚。
手工管理 KVM（virsh + libvirt + 自己写脚本）：适合 1 到 3 台机器、VM 数量个位数、且负责人对 Linux 很熟的场景。好处是完全可控、没有额外组件、出了问题直接看 libvirt 日志。坏处是没有统一的集群视图、没有原生的 HA 与迁移编排，一切靠脚本，规模一上来就是灾难。别用手工方式管理超过两台机器，这是我踩过的坑——你会花在写脚本上的时间超过学一套管理平台的时间。
Proxmox VE：单节点体验好、Web 界面直观、开箱带有集群、Ceph 超融合、备份工具（vzdump/PBS）、以及基于 corosync 的 HA。它的集群模型相对扁平（没有 oVirt 那种数据中心/集群/存储域的多层抽象），上手快，中小团队友好。规模上，几十台以内、存储用 Ceph 或本地 + ZFS 的场景，Proxmox 往往是更省心的选择。它的短板在于大规模下的集中管理与细分权限模型不如 oVirt/商业方案，且商业支持需要订阅（具体订阅政策与价格以厂商官方公告为准）。
VMware vSphere：生态最成熟、文档与人才储备最充足、vMotion/DRS/HA 的组合久经考验。但近年 vSphere 的许可证与订阅模式发生过调整（以 Broadcom/VMware 官方公告为准），对小规模用户来说成本结构变化明显。如果你的团队已经熟悉 VMware、有存量许可、或者业务依赖某些只在 VMware 生态里验证过的方案，继续用是合理的；如果是从零开始且规模不大，2026 年再选它是需要认真算一笔账的。
oVirt 的位置在哪？它是"想要企业级的多层管理与细粒度权限、又希望开源自持"这一档的选择，特别合适有几台到几十台物理机、有专职运维团队、需要清晰的数据中心/集群/存储域分层、且愿意自己承担维护的场景。它源自 Red Hat 的 RHEV 血统，模型严谨，代价是学习曲线陡、组件多。
问题：图省事把 Engine 部署为集群里某台 Host 上的一台 VM，主机故障时管理端一起不可用。为什么：Engine 通过 VDSM 指挥节点，它自己若依赖被它管理的资源，就形成了循环依赖，HA 决策根本无从发起。怎么判断：拔掉 Engine 所在 Host 的管理网（测试环境里做），看 Engine 是否还能访问——如果它自己就失联了，就是这个坑。怎么避：Engine 独立部署在集群之外的物理机或另一套环境，管理工作网独立；同时打开 Engine 数据库与配置的定期备份，并至少演练过一次恢复。
问题：用本地盘建存储域，VM 界面上也能勾 HA，但主机宕机后 VM 在别的节点起不来。为什么：本地域的磁盘只存在于单台主机，其他节点没有访问路径，迁移与 HA 的前提（共享存储）根本不成立。怎么判断：试着对 VM 做一次在线迁移，如果目标主机列表为空或报"存储域不可访问"，就是本地域。怎么避：上线前按业务重要性分层——需要迁移和 HA 的 VM 必须落在 NFS 或块共享域上；明确无状态、可停机的才放本地域，并在 VM 命名或描述里标注清楚。
问题：配置了电源管理但从未实际测试，主机真宕机时 VM 长时间停在 Unknown，需要人工确认。为什么：Engine 必须拿到 fence 成功的证据才敢在别处重启 VM，IPMI 凭据错误、网段不通、BMC 固件问题都会让 fence 失败。怎么判断：在每台 Host 上点一次电源管理的"测试"，并对测试环境的一台主机执行一次真实的强制重启验证。怎么避：把 fence 测试纳入季度例行巡检；BMC 网口接独立的带外网络并配置静态地址；凭据统一管理并设置过期提醒。
问题：业务突发流量（备份窗口、大批量同步）导致 Engine 心跳超时，触发 fence，活着的主机被强制重启。为什么：ovirtmgmt 与业务流量争抢同一条链路，心跳包被丢。怎么判断：查看故障时间点的网络流量图与 Engine 日志里 Host 变为 Non Responsive 的时间是否吻合。怎么避：管理网、迁移网、存储网、业务网各自独立网口或绑定组；给管理网配 active-backup 双口；对备份类任务做带宽限速，避开监控心跳的敏感阈值。
问题：习惯性给每台 VM 建快照留"后悔药"，几个月后存储域写满，整批 VM 自动暂停，业务全停。为什么：快照增量文件随写入持续增长，占用与日俱增，且 IO 路径变长拖慢性能。怎么判断：定期检查存储域的剩余空间告警与每台 VM 的快照链长度（链超过两三层就该处理）。怎么避：制定快照保留规则（如变更窗口快照保留不超过 72 小时），设置存储域低水位告警（低于 20% 就介入），把真正的长期保护交给独立备份方案而不是快照。
libvirt 是单机视角的抽象层，它解决的是"怎么把一台机器的虚拟化用统一 API 管起来"，但它天然不知道集群里还有谁。oVirt 补的是集群视角：谁有多少空闲资源、VM 该调度到哪、存储域在哪儿、网络怎么跨主机一致、主机失联后要不要接管。小规模（两三台、VM 个位数、无专职运维）我不建议上 oVirt，学习成本和组件数量都偏重，Proxmox VE 或者干脆手工管理更务实。超过五台物理机、需要多人分权限操作、需要清晰的存储与网络分层时，oVirt 的价值才明显体现出来。
三台是最小可用配置，原因有两层。一是资源层面：两台的话每台负载必须长期低于 50%，否则一台挂了剩下那台接不住，实际生产中很难维持这个水位；三台时每台可以跑到 60% 以上仍有余量。二是仲裁层面：集群需要判断"谁才是多数派"，奇数节点天然能形成多数派，偶数节点在分区时容易出现各占一半的僵局，需要额外配置仲裁设备（如第三个仲裁节点或存储侧的仲裁机制）才能解决。因此三台是起步，四台在资源利用率上反而可能不如三台均衡。
做不到无感知。oVirt 的 VM HA 本质是"检测到故障 → fence 隔离原主机 → 在另一台主机上冷启动这台 VM"，VM 内部的操作系统经历的是一次意外断电后的重新开机：文件系统要 journal 恢复、数据库要做崩溃恢复、应用要重新拉起，全过程通常是分钟级。真正要求秒级连续性的业务，应该在应用层面做主备或集群（数据库主从、应用多副本 + 负载均衡），把虚拟机 HA 当作兜底而不是主力。同时要理解：HA 恢复的是"能不能起来"，不是"有没有丢事务"。
严格来说不能安全地做。fence 是整个 HA 的地基，没有可靠的隔离手段，Engine 就没有证据证明原主机已经停止写磁盘，擅自启动备用实例会造成双写损坏。oVirt 支持若干种 fence agent（IPMI/iDRAC/iLO、SSH、PDU 等），但它们都要求有一条独立于业务网与管理网的通道。如果机器确实没有带外口，可以考虑带 SNMP 的可控 PDU 做电源级隔离（断电也算 fence），或者退一步：不做自动 HA，改为人工确认后手动恢复，虽然慢但安全。租物理机时，建议优先选带独立管理口的机型。
看团队能力和业务重要性。内部 OA、测试环境、中间件这类，NFS 域足够：部署简单，磁盘文件能直接看到、能直接拷走做冷备，排障门槛低，出问题也能靠通用 Linux 知识解决。核心数据库、对延迟敏感的服务，iSCSI 或 FC 块域更合适，IO 路径短、性能更接近裸设备，但要有人能管 LUN 掩码、多路径、CHAP 与 LVM 卷组。没有存储运维经验的团队，我建议先用 NFS 把流程跑顺，等确实遇到 IO 瓶颈再评估块存储，而不是一上来就上块域然后在排障上卡几个月。
通常不会。VM 的进程由各 Host 上的 libvirt/QEMU 维持，Engine 只是控制面，它掉线不会直接杀掉正在跑的 QEMU 进程。真正受影响的是"控制能力"：你不能开机、关机、迁移、改配置、创建快照，也看不到准确的最新状态，告警可能失真。如果此时恰好有主机故障，HA 也不会触发，因为没人做决策。所以 Engine 的可用性虽然不影响存量 VM 的运行，却直接影响故障恢复能力，必须把它当作高优先级组件对待：独立部署、数据库定期备份、考虑做 Engine 的高可用方案（具体方式以官方文档为准），并验证过恢复流程。
三条比较关键。第一是存储网络：如果用 iSCSI 或 NFS，节点到存储之间需要稳定、低丢包的链路，建议万兆或双千兆绑定，并与业务网隔离，具体带宽与隔离方式要在下单前和服务商确认。第二是带外管理网：每台机器的 BMC/iDRAC 要能互通且能被 Engine 访问，最好独立网段，这是 fence 的前提。第三是交换机侧的配合：如果打算做 LACP 绑定，必须确认机柜交换机支持并愿意配合配置聚合组，否则改用 active-backup 主备模式更稳妥。像一万网络这类服务商在华南、华东、华北以及中国香港、海外多地有机房资源，下单前把端口数量、万兆能力、BMC 网段、是否支持聚合这几项问清楚，比事后改造省事得多。
如果你已经决定要在租来的物理机上自建 oVirt，我给一条可执行的落地路径，按优先级排，前面的没做完不要往后走。
第一，先把"要不要自建"这件事重新过一遍：VM 数量是否稳定在 10 台以上、是否有人能长期维护、是否有明确的数据不出自有物理机的诉求。三条里命中不足两条，我倾向于直接租云主机或裸金属，把精力放在业务上。这一条不是泼冷水，是我见过太多"搭好了没人管，一年后变成没人敢碰的老系统"。
第二，机器规划上留足余量：计算节点至少三台，Engine 独立一台（可以是配置不高的机器或在另一套环境上），共享存储单独一套。别把 Engine 塞进受管集群，别把管理网和业务网挤在一个口子上。
第三，网络先行：下单前就确认交换机端口数量、是否支持万兆或链路聚合、BMC 管理口能否接入独立网段。这些在机房侧改起来成本远高于你多订两个端口。
第四，存储域选型从保守起步：没有专职存储运维就先用 NFS 共享域，把迁移和 HA 跑通，再考虑块存储。本地存储域只放无状态负载，并在描述里写清楚。Gluster 超融合除非你有明确把握，否则不要做生产首选，且上线前务必核对当前 oVirt 版本对它的支持说明。
第五，HA 相关三项一次做全：电源管理配好并逐台测试、VM 启用 lease、管理网与业务网物理分离。做完全套之后，在业务低峰期真实拔一次电做演练——不演练的 HA 等于没有 HA。
第六，备份三层到位并演练恢复：Engine 配置与数据库（最高优先级）、VM 层备份（导出域或对接备份方案）、Guest 内数据备份。恢复顺序写成文档，至少演练一次。
在硬件与机房这一侧，一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。自建虚拟化这件事，机器本身反而是最简单的部分，难的是存储、网络与长期运维——选机房时把可维护性（IPMI 可用性、端口扩展、能否配合网络配置）和机器配置一起评估，会少走很多弯路。
1. oVirt 官方管理指南（oVirt Administration Guide）：数据中心、集群、主机、存储域与逻辑网络的层级模型，存储域类型（NFS/GlusterFS/FCP/iSCSI/本地）的定义与限制，VM 高可用、电源管理与 vm lease 的工作机制。
2. oVirt 官方安装指南（oVirt Installation Guide）：Engine 与 Host 的部署要求、PostgreSQL 的配置与备份恢复、PostgreSQL 版本与 Engine 的配套关系。
3. oVirt 官方 REST API 指南：备份 API、增量备份与导出域（Export Domain）相关接口的定位与能力边界。
4. oVirt 官方发行说明与版本支持说明：GlusterFS 超融合支持状态、存储域功能在各版本中的变化（建议按实际部署版本逐条核对）。
5. libvirt 官方文档（libvirt.org）：域 XML 格式、存储池与存储卷定义、网络与桥接配置、CPU pinning 与 NUMA 相关元素、hugepages 配置方式。
6. QEMU 官方文档（qemu.org）：磁盘缓存模式（writethrough / writeback / none / directsync）的语义、qcow2 与 raw 镜像格式特性、快照与镜像提交（commit）机制、virtio 设备模型。
7. Linux 内核 KVM 文档（docs.kernel.org / kernel.org）：KVM 虚拟化架构、NUMA 与内存相关机制。
8. Red Hat 公开文档（docs.redhat.com）：RHEL 虚拟化部署与管理指南中关于共享存储、fencing 与集群仲裁的说明，以及高可用集群中隔离（fence）机制的设计原则。
9. Linux 内核与发行版网络文档：Linux bridge 与 Open vSwitch 的配置差异、网卡绑定（bonding）各模式（active-backup、802.3ad/LACP）对交换机侧配合的要求。
10. 各虚拟化平台官方公告与文档：Proxmox VE 官方文档（集群、Ceph 超融合、备份工具），VMware / Broadcom 官方公告（vSphere 许可证与订阅模式变更，具体条款与价格以厂商官方公告为准）。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
