KVM 在底层如何工作
KVM 通过暴露 /dev/kvm 字符设备将 Linux 内核转换为 Type-1 hypervisor。用户空间进程(通常是 QEMU)打开该设备,要求内核创建虚拟 CPU,然后使用硬件虚拟化扩展直接在物理 CPU 上运行客户机指令。内核处理特权事件;其他一切以原生速度执行。
三个组件使 KVM 工作。第一,kvm.ko 内核模块管理 CPU 和内存虚拟化,并暴露 /dev/kvm 接口。第二,特定架构的模块 — 用于 Intel VT-x 的 kvm-intel.ko 或用于 AMD-V 的 kvm-amd.ko — 在通用 KVM API 与底层 CPU 的虚拟化指令之间转换。第三,用户空间 hypervisor 进程(如 QEMU、cloud-hypervisor 或 Firecracker)提供设备模拟:虚拟磁盘、NIC、USB 控制器,以及 BIOS 或 UEFI 固件。因为 Linux 内核本身就是 hypervisor,所以每个 Linux 调度器、内存管理器和安全功能都以与对原生进程相同的方式应用于 VM。从内核的角度来看,KVM 客户机只是一个重量级进程,这就是为什么 top、perf 和 cgroups 等工具无需修改即可使用。
KVM vs OpenVZ vs VMware ESXi vs Hyper-V
KVM 提供完整的硬件虚拟化,每个 VM 都有独立的客户内核。OpenVZ 使用操作系统级容器化,每个容器共享主机内核。VMware ESXi 是专有的裸金属 Type-1 hypervisor,有自己的内核(VMkernel)。Hyper-V 是微软基于 Windows 的 Type-1 hypervisor。只有 KVM、ESXi 和 Hyper-V 提供真正的、隔离的客户内核。
OpenVZ(及其继任者 Virtuozzo)是容器技术,而不是 hypervisor。每个 OpenVZ 容器共享主机的 Linux 内核,这意味着您不能运行不同的内核版本、不能加载自定义内核模块,也不能运行非 Linux 操作系统。权衡是密度:因为没有每 VM 内核开销,OpenVZ 主机可以将更多容器塞入相同的硬件,这就是为什么低端共享 VPS 方案经常使用它。VMware ESXi 是 Type-1 虚拟化的企业标准,但作为闭源产品发售,具有按插槽授权,历史上将其定价排除在通用 VPS 主机之外。Hyper-V 在 Windows 服务器环境中占主导地位,与 Active Directory 和 System Center 紧密集成,但对于 Linux 重型主机机群是较少见的选择。KVM 已成为现代 VPS 主机的默认,因为它是开源的、内核主线化的,支持任何在 x86_64 或 aarch64 上运行的客户操作系统,并具有成熟的管理生态系统(libvirt、oVirt、Proxmox、OpenStack Nova)。
为什么 KVM 是 VPS 的现代默认
KVM 成为占主导地位的 VPS 技术,因为它为每个客户提供真正的、隔离的内核,而无需支付 VMware 风格的授权费。它支持 Linux、Windows、BSD 和 Solaris 客户机,在通用 x86_64 和 ARM 硬件上运行,并集成到每个主要云编排堆栈中 — OpenStack、Proxmox VE、通过 KubeVirt 的 Kubernetes 和 AWS Nitro 都基于它构建。
三股力量汇聚使 KVM 成为标准。第一,硬件虚拟化扩展变得普及:Intel VT-x 在 2006 年随 Core 2 芯片发布,AMD-V 在早期 Athlon 64 中发布,因此到 2010 年代初,基本上每个服务器 CPU 都能以接近原生的速度托管 KVM。第二,Linux 社区拒绝在主线中采用 Xen 风格的半虚拟化,但在 2007 年将 KVM 主线化,立即给每个发行版提供了内置 hypervisor。第三,公共云生态系统大量投资:Google Cloud Engine 在 KVM 上启动,AWS 从 Xen 迁移到基于 KVM 的 Nitro 架构,OpenStack 将 KVM 标准化为参考 hypervisor。较小的 VPS 服务商受益于这种引力,因为运行超大规模机群的相同工具 — libvirt、virtio 驱动程序、cloud-init — 也能在单个机柜的通用服务器上运行。
真实性能特征:CPU steal、IO 和开销
在适当配置的 KVM 主机上,预计相比裸金属有个位数百分比的 CPU 开销,本地网络路径增加亚毫秒级网络延迟,使用 virtio-blk 或 virtio-scsi 与半虚拟化驱动程序时,可达到原生磁盘 IOPS 的 80-95%。CPU steal 时间持续超过 5% 是主机超额分配的典型迹象,也是强烈的升级信号。
三个数字对生产中的 KVM 客户机很重要。CPU steal 时间在 /proc/stat 中作为第八字段公开,衡量虚拟 CPU 准备运行但物理 CPU 忙于执行其他客户机的时间百分比。低于 1-2% 的任何值都是正常的背景噪声;持续超过 5% 的值意味着主机超额分配,您的工作负载被限制。IO wait 由 iostat 和 top 等工具显示,衡量 CPU 在磁盘或网络上被阻塞的时间百分比。使用 virtio 半虚拟化驱动程序和现代 NVMe 备份存储,在应该是 CPU 受限的工作负载上持续 IO wait 超过 20% 是磁盘子系统饱和的强烈迹象。virtio-net 上的网络吞吐量应达到物理 NIC 线速的 80-95%;明显低于此值则指向配置错误的卸载或旧的模拟 e1000 驱动程序。
何时不应使用 KVM
在三种情况下,KVM 不是正确选择:超高密度容器化工作负载,其中每 VM 内核开销占主导地位;Windows 授权敏感部署,其中 Hyper-V 的 SPLA 定价显著更便宜;以及某些低延迟硬件直通场景,其中 SR-IOV 或 GPU 直通在您特定的 NIC 或 GPU 型号上支持不佳。
对于不需要内核隔离的容器化微服务,直接在裸金属上运行的 Linux 容器(Docker、Podman、Kubernetes)将比任何基于 KVM 的 VPS 多打包 3-5 倍,因为每个容器只是带有命名空间和 cgroups 的进程组。密度敏感的低成本 VPS 服务商出于同样原因历史上选择 OpenVZ。Windows 重型部署 — 特别是通过 SPLA 购买 Windows Server 授权的部署 — 由于 Microsoft 在竞争 hypervisor 上对客户机授权的定价方式,有时在 Hyper-V 上的费用显著低于 KVM。最后,某些硬件直通场景在 KVM 上仍然痛苦:GPU 直通需要 IOMMU 组干净隔离,某些消费者 NIC 没有 SR-IOV 支持,NVMe 驱动器的 PCIe 直通有时会触发重置错误的解决方法。对于 95% 的通用 Linux VPS 工作负载,这些情况都不适用,KVM 是正确的默认选择。
如何验证 VPS 真的是基于 KVM
在 Linux 客户机内,运行 `systemd-detect-virt` — 它应该打印 `kvm`。使用 `lscpu` 交叉检查('Hypervisor vendor' 行应读为 'KVM')和 `dmesg | grep -i kvm`。如果您看到 'OpenVZ'、'lxc' 或 'VMware',则您的服务商使用不同的技术,即使营销宣传声称相反。
在签订合同之前,在试用 VPS 上运行一系列小型诊断。运行 `systemd-detect-virt` 进行规范检测输出。运行 `cat /proc/cpuinfo | grep -E 'vmx|svm'` 以确认硬件虚拟化扩展已透传(某些服务商剥离它们,破坏嵌套虚拟化)。运行 `uname -r` 以验证您看到的是客户机特定内核,而不是共享主机内核 — 在真正的 KVM VPS 上,您可以通过 `apt install linux-image-...` 或 `dnf install kernel-...` 安装不同的内核并重新启动到该内核。在 OpenVZ 上您不能。最后,检查 `/proc/user_beancounters` — 如果该文件存在,无论营销文案如何说,主机都在运行 OpenVZ。