KVM、OpenVZ 与 LXC 对比：你的 VPS 虚拟化类型究竟允许你做什么

同一个页面上的两款 VPS 套餐。四核 vCPU、8 GB 内存、160 GB 存储，价格也几乎相同。一个写着 KVM，另一个写着 OpenVZ。两个页面都没有解释这个词改变了什么。

它改变的是你被允许运行什么。VPS 虚拟化类型不只是性能上的一个脚注。它们决定你是否掌控内核、能否使用 Windows，以及 Docker 能否在没有服务商介入的情况下运行。KVM、OpenVZ 与 LXC 之争，首先是能力问题，其次才是速度问题。

本指南涵盖与这次购买决策最相关的三个名称。Xen、VMware、Hyper-V 等虚拟化平台同样存在，但不在这次三方比较的范围内。

TL;DR（太长不看版）

• KVM 为每台 VPS 提供独立的客户机内核。Docker 正常运行，Windows 在技术上可行，通常还能加载内核模块或引导自定义内核。不过，单靠 KVM 并不保证独享 CPU 或内存；资源承诺仍取决于服务商和套餐。
• OpenVZ 的 VPS 套餐通常是共享宿主机内核的 Linux 容器。只有当服务商使用兼容的内核和模板配置时，Docker 才能在 OpenVZ 7 上运行。你无法替换宿主机内核，超出内存的部分由服务商控制的 VSwap 处理，而不是客户机自行管理的普通磁盘交换分区。
• LXC 同样共享宿主机内核，但它构建在主线 Linux 的隔离机制之上。只要宿主机启用了所需功能，Docker 就能运行，不过对于需要最大隔离和在线迁移的工作负载，Proxmox 建议把容器嵌套在 QEMU 虚拟机中。
• 容器通常更容易在运行时调整规格。KVM 同样可以支持 CPU 和内存热插拔，所以"KVM 一定要重启"并不是可靠的购买依据。请向服务商确认其平台实际支持什么。
• 对于从不需要 Docker、Windows 或内核级定制的静态站点或小型 LAMP 环境，实际差别可能很小。但隔离性、生命周期和资源策略仍可能不同。

导致其他所有差异的那一个差异

KVM 为宿主机上的每台 VPS 提供独立的客户机内核。OpenVZ 容器和 LXC 容器则使用宿主机启动的内核。

KVM 是面向 x86 硬件的全虚拟化解决方案 （需要虚拟化扩展）。它自 2.6.20 起并入主线 Linux 内核。每台客户机看到的是虚拟硬件，并启动自己的操作系统和内核。

容器类型的工作方式不同。LXC 是 面向 Linux 内核隔离机制的用户空间接口，包括命名空间、cgroups、capabilities、seccomp 和安全配置文件。它的目标是在不启动独立内核的前提下，提供接近普通 Linux 安装的环境。

OpenVZ 容器大体上遵循同样的共享内核模型，尽管 OpenVZ 使用自己的平台和内核栈。OpenVZ 7 既能管理容器，也能管理 KVM 虚拟机，但当零售 VPS 套餐标注为"OpenVZ"时，所售产品通常是容器类型。

下面所有的能力差异都源于这一点。内核模块必须加载到你所掌控的内核中。不同的操作系统需要不同的内核。Docker 需要内核级的命名空间，而它必须在内核本身所在的位置可用。在这条边界的 KVM 一侧，虚拟机管理程序层遵循一种通常划分为 第 1 类和第 2 类虚拟机管理程序.

LXC 常见于 Proxmox 环境，包括自管服务器和部分主机平台。你能否启用 LXC 的高级功能，取决于谁掌控那台宿主机。

阅读

2022 年 KVM 与 OpenVZ 对比:哪种虚拟化技术更出色?

每种类型允许你运行什么

决定购买的几条主线是：内核控制权、客户机操作系统支持、Docker 兼容性、内存行为、规格调整以及资源策略。

该选哪一个？ 当你需要 Windows、自定义内核、客户机加载的模块，或一个行为可预期的 Docker 宿主时，KVM 是最干脆的答案。OpenVZ 和 LXC 可以是高效的 Linux 环境，但把内核层面的决定权留给了服务商。

这是一张能力地图，不是性能测试。它没有涉及存储延迟、网络质量、CPU 代次、宿主机负载，也没有涉及服务商的资源分配策略。使用同一种虚拟化类型的两家服务商，交付的机器可能相差很大。

买家浪费时间的地方，正是那些"有条件"的格子。我曾在一台容器型 VPS 上部署 VPN，而宿主机侧所需的网络功能并未开放。接口始终起不来，最终的修复需要提交工单，而不是在客户机内改配置。选择容器套餐时，请询问服务商是否开放了你的 VPN 所需的那个具体设备或内核功能。使用 KVM 时，这通常由你在客户机内自行掌控。

为什么 Docker 是决定大多数购买的问题

一旦 Docker 出现在你的需求里，容器型 VPS 与 KVM VPS 的比较就不再抽象。Docker 本身要用到内核命名空间、cgroups、网络和存储驱动。在 KVM 中，这些能力属于你所掌控的客户机内核。在 OpenVZ 或 LXC 中，它们最终取决于宿主机。

OpenVZ 上的 Docker

OpenVZ 上是否支持 Docker，是在你之上的层面做出的供给决策。一篇 SolusVM 支持文章 指出，从某个 3.10 系内核版本起，Docker 可以在 OpenVZ 7 内运行，但同时也说明 Docker 无法配合标准的旧式预置模板工作。容器必须使用 EZ 模板或合适的自定义模板。同一篇文章还排除了 CentOS 8 客户机。

那么，Docker 能在 OpenVZ 上运行吗？有时可以。服务商必须围绕兼容的 OpenVZ 7 内核和合适的模板路径来搭建服务。如果套餐页面没有明确说明，请在购买前询问客服，并把答复留成书面记录。

当宿主机配置不兼容时，在 VPS 内部调整 Docker 参数并不能解决根本问题。你需要服务商更改容器配置，或把你迁移到另一种虚拟化类型。

LXC 上的 Docker

当宿主机开放了所需功能时，Docker 可以在 LXC 内运行。在 Proxmox 中，这通常包括容器嵌套和 keyctl ，用于非特权容器。

更重要的购买信号是平台方自己的建议。Proxmox 文档指出， 把容器嵌套在 Proxmox QEMU 虚拟机内仍是推荐做法 适用于要求最大隔离和在线迁移能力的场景，而不是直接放在 LXC 系统容器里运行。

如果 LXC 宿主机由你掌控，你可以自行权衡这个取舍，并按自己的节奏测试升级。如果你租用的是 LXC VPS，那么内核、安全配置和高级功能开关都由服务商掌控。请确认受支持的配置，而不要想当然地以为容器内有 root 权限就够了。

KVM 上的 Docker

Docker 通常能正常工作，是因为 Linux 客户机掌控着自己的内核环境。客户机之上既没有 LXC 嵌套开关，也没有 OpenVZ 模板要求。但你仍然需要一个受支持的 Linux 发行版、兼容的内核，以及足够承载该负载的内存和存储。

拥有客户机内核，也意味着要维护它。在非托管 VPS 上，更新、防火墙规则、Docker 安全和备份仍然由你负责。

核心要点: Docker 并不会让 OpenVZ 或 LXC 变得不可行，但它会把服务商的配置变成你应用可靠性的一部分。对于租用的生产环境 Docker 宿主，KVM 去掉了这一层额外依赖。

"4 vCPU"是否意味着四个独享 CPU 核心

自己的监控显示 CPU 空闲，机器却明显卡顿，这是人们描述最多的症状。让这种情况得以出现的，正是容器虚拟化。争抢发生在客户机能看到的那一层之下，所以客户机自己的指标看不出任何异常。

机制正是开销本身足够低。一个容器给宿主机带来的成本远低于一台完整虚拟机，因此同样的硬件能塞下更多容器。这种密度制造起来便宜，从客户机内部又难以察觉，于是超售在 OpenVZ 上比在 KVM 上结构性地更容易。KVM 并不能阻止服务商把宿主机塞满，但它会为每台客户机承诺真实内存和真实 CPU 份额，从而给塞的程度设下一个算术上限。关于诊断的一面，我们另有一篇讲解 如何判断你的服务商是否在超售.

内存的表现同样不同。在 OpenVZ 上你无法把磁盘交换分区当作额外内存使用，所以套餐页面上的内存数字是一堵墙，而不是一段缓坡。KVM 客户机在内存吃紧时会变慢。OpenVZ 容器在内存吃紧时则会被杀掉进程。

还有一个关于隔离的后果，而这正是人们最容易低估的。容器的内存可以从宿主机寻址，KVM 客户机的内存则不行。客户机内的磁盘加密仍然能在磁盘被盗时保护你，但它无法保护运行中容器的密钥不被那台正在运行它的机器读取。如果你的威胁模型把宿主机运营方也算在内，共享内核就是错误的底座。客户机内部的任何配置都改变不了这一点。

核心要点: 套餐页面上同样的数字，在不同类型下是不同性质的承诺。在 KVM 上它是一份分配额。在 OpenVZ 上它是一个你与他人共享的上限。

OpenVZ 在哪些场景仍然合理，以及它的走向

如果你运行的是静态站点或流量不大的 LAMP 环境，也许根本不会碰到 OpenVZ 所限制的那些能力。不需要 Windows，不需要自定义内核，不需要客户机加载模块，也不需要跑生产环境的 Docker。对这类范围有限的负载，一个运维得当的 OpenVZ 容器仍然能胜任。

生命周期比十年前更需要留意。OpenVZ 7 基于 RHEL 7 的内核分支，版本号为 3.10。仅凭版本号并不能证明一个仍在维护的企业级内核缺少安全修复，因为厂商会回移补丁。但它确实意味着，你应当核实与那些期待更新内核接口的软件之间的兼容性。

The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the 官方生命周期政策.

这并不会让今天正常运行的 OpenVZ 站点出问题。但在你把一个新的、要长期运行的负载托付上去之前，服务商的迁移计划就变得重要了。请询问运行的是哪个 OpenVZ 或 Virtuozzo 版本、安全修复如何交付，以及有哪条迁移路径可走。

当套餐页面没有写明虚拟化类型时，请询问客服，而不要从价格去推断。这个答复值得留成书面记录。

按工作负载来选择

从需求出发，而不是从技术出发。

当工作负载需要自己的内核时，选择 KVM

当你需要以下任意一项时，KVM 就是直接的选择：

• 以 Windows 作为客户机操作系统
• 自定义内核
• 由客户机加载的内核模块
• 无需依赖容器套容器的生产环境 Docker
• 嵌套虚拟化，前提是服务商开放了该功能
• 由客户机掌控的交换分区与内核调优

Windows 是决定性因素，因为 OpenVZ 和 LXC 的容器都使用 Linux 宿主机内核。至于应用本身该选 Linux 还是 Windows，那是另一个问题，牵涉软件兼容性、运维管理和授权。请参阅 Linux 与 Windows VPS 对比 来做这个决定。

当你想要一个高效的 Linux 系统容器时，选择 LXC

当工作负载只跑 Linux、不需要独立内核，并且能从低开销或宿主机侧的快速调整中受益时，LXC 是合理的。尤其在你自己掌控 Proxmox 或 LXC 宿主机时特别有用。

对于租用的 LXC VPS，请核实是否支持 Docker、所需设备、安全模式、备份行为，以及能否启用高级功能。

对于简单且已核实的 Linux 负载，可以考虑 OpenVZ

对于基础网站、小型 LAMP 环境、DNS 服务或类似的常规 Linux 负载，在满足以下条件时，OpenVZ 仍然可以接受：

• 服务商明确写出了平台版本。
• 你的软件支持现有的内核环境。
• 你不需要 Windows，也不需要定制内核。
• 要么不需要 Docker，要么明确支持 Docker。
• 服务商有一份可信的安全与迁移计划。
• 价格或运维模式给了你选择它的真实理由。

不要仅仅因为一篇旧的对比文章说 OpenVZ 总是更便宜就选它。请比较当前的套餐、支持、资源策略和迁移选项。

如果你的答案落在 KVM 上，那是约束条件在起作用，而不是个人偏好。Cloudzy 的 KVM虚拟专用服务器 在 AMD EPYC 与纯 NVMe 之上 60 秒即可启动，每个实例都拥有自己的客户机内核。内核模块可以加载，自定义内核可以引导，Linux 和 Windows 客户机都受支持。 Docker 就在应用市场里 ，省得你自己动手安装。

常见问题

systemd-detect-virt