命令与 XML 使用通用示例,需按宿主版本和实际资源调整。网络地址采用文档地址段,实际部署应选择不冲突的私网;镜像修改与设备直通的适用条件见对应章节。
KVM (Kernel-based Virtual Machine) 是 Linux 内核原生的虚拟化基础设施,将 Linux 操作系统本身转化为一个 Type-1 Hypervisor。自 2007 年合入 Linux 2.6.20 主线内核以来,KVM 已成为全球云计算基础设施的基石 —— Google Cloud、AWS Nitro、OpenStack、Proxmox VE 等主流平台均构建在 KVM 之上。
1. 虚拟化基础#
1.1 什么是虚拟化
虚拟化(Virtualization)的核心思想是在单个物理硬件上运行多个隔离的操作系统实例。中间的软件层负责管理物理资源(CPU、内存、磁盘、网络)并将其抽象为一组虚拟资源,分配给各个虚拟机(Guest VM)。
graph TB
subgraph "Type-1 (Bare Metal)"
HW1[Physical Hardware]
H1[Hypervisor - runs directly on hardware]
VM1[VM 1]
VM2[VM 2]
VM3[VM 3]
end
subgraph "Type-2 (Hosted)"
HW2[Physical Hardware]
OS2[Host OS]
H2[Hypervisor - runs as host OS process]
VM4[VM 1]
VM5[VM 2]
end
HW1 --> H1
H1 --> VM1
H1 --> VM2
H1 --> VM3
HW2 --> OS2
OS2 --> H2
H2 --> VM4
H2 --> VM5| 类型 | 代表产品 | 特点 |
|---|---|---|
| Type-1 (Bare Metal) | VMware ESXi, Microsoft Hyper-V, Xen, KVM | Hypervisor 位于硬件与客户机之间;实际性能依实现与负载而变 |
| Type-2 (Hosted) | VirtualBox, VMware Workstation, QEMU (纯模拟) | Hypervisor 作为 Host OS 的进程运行,有额外开销 |
1.2 KVM 的类型定位
KVM 在类型划分上有一个著名的"哲学之争":
- 观点 A(KVM is Type-1):KVM 是一个内核模块(
kvm.ko),加载后 Linux 内核本身变成了 Hypervisor,直接控制硬件虚拟化能力(VT-x/AMD-V),Guest VM 以独立进程运行。Hypervisor 部分工作在 Ring 0。 - 观点 B(KVM is Type-2):KVM 仍然运行在一个完整的 Linux OS 之上,依赖 Host OS 的调度器、内存管理、驱动等。没有 Linux 内核,KVM 便无法运作。
主流共识 学术界和业界主流将 KVM 归类为 Type-1 (Bare Metal) hypervisor。核心论据是:KVM 将 Hypervisor 的核心功能(CPU 虚拟化、内存虚拟化)集成在内核空间(Ring 0),Guest VM 直接在 VMX non-root 模式下执行,无需经过 Host 用户态中转。Linux 在此扮演的不是"Host OS"角色,而是提供低层服务(调度、内存管理、I/O 驱动栈)的通用基础层。
1.3 硬件需求
CPU 标志只能证明当前环境暴露了相应能力。固件是否开启、嵌套虚拟化限制、内核模块、/dev/kvm 权限与实际 QEMU 启动结果需要分别检查。以下示例输出用于说明,不是本次运行证据。
| 厂商 | CPU 虚拟化扩展 | 内存虚拟化扩展 | /proc/cpuinfo 标志 |
|---|---|---|---|
| Intel | VT-x (VMX) | EPT (Extended Page Tables) | vmx, ept |
| AMD | AMD-V (SVM) | NPT (Nested Page Tables) | svm, npt |
BIOS/UEFI 设置 许多主板默认关闭虚拟化扩展。在使用 KVM 之前,必须在 BIOS/UEFI 中启用 Intel VT-x 或 AMD SVM。企业级服务器(Dell PowerEdge、HPE ProLiant 等)通常默认开启。
验证硬件支持:
# 检查 CPU 虚拟化标志(输出 > 0 表示支持)
egrep -c '(vmx|svm)' /proc/cpuinfo
# Intel 输出 vmx 数量,AMD 输出 svm 数量,等于逻辑 CPU 核数
# 更精确的检查(区分 Intel/AMD)
lscpu | grep -i virtualization
# Intel: VT-x
# AMD: AMD-V
# 使用 kvm-ok 工具(需安装 cpu-checker 包)
kvm-ok
# INFO: /dev/kvm exists
# KVM acceleration can be used
# 验证 KVM 内核模块已加载
lsmod | grep kvm
# kvm_intel 368640 0
# kvm 1105920 1 kvm_intel
# (AMD 平台显示 kvm_amd 而非 kvm_intel)1.4 KVM 的核心优势
KVM 之所以成为 Linux 虚拟化的事实标准,核心在于"内核即 Hypervisor"这一设计:
| 优势 | 说明 |
|---|---|
| 内核级性能 | CPU 执行可使用硬件虚拟化;VM exit、设备模拟及 ioctl 仍有开销,性能依工作负载而变 |
| 继承 Linux 所有能力 | 调度器(CFS/EEVDF)、内存管理(THP、KSM)、cgroups 资源限制、NUMA 感知、文件系统、网络协议栈 |
| 安全集成 | SELinux(sVirt)、AppArmor、seccomp 直接作用于 QEMU 进程,实现 VM 级安全隔离 |
| 驱动兼容性 | Linux 支持的所有硬件驱动自动可用于 Host,无需维护独立驱动栈 |
| 持续主线化 | KVM 代码合入 Linux 主线内核,随内核版本持续演进,不会被厂商锁定 |
| 零许可成本 | GPLv2 许可,无商业授权费用 |
2. KVM + QEMU:内核与用户态的协作#
2.1 角色分工
KVM 本身只负责CPU 和内存虚拟化——这是性能关键路径,必须在内核空间完成。对于磁盘、网卡、显卡、USB 等外设的模拟,则需要用户态程序提供。在 Linux 生态中,这个用户态角色的扮演者就是 QEMU。
graph TD
subgraph "Guest VM"
G_APP[Applications]
G_KERN[Guest Kernel]
end
subgraph "Host Userspace (Ring 3)"
QEMU[QEMU Process]
Q_DEV[Device Emulation]
Q_MEM[Memory Management]
end
subgraph "Host Kernel (Ring 0)"
KVM[KVM Kernel Module]
K_CPU[CPU Virtualization]
K_MMU[MMU Virtualization]
LK[Linux Kernel Services]
end
subgraph "Physical Hardware"
CPU[CPU with VT-x/AMD-V]
MEM[RAM]
DEV[Devices]
end
G_APP --> G_KERN
G_KERN -.->|VM Entry/Exit| KVM
QEMU -->|ioctl /dev/kvm| KVM
QEMU --> Q_DEV
QEMU --> Q_MEM
KVM --> K_CPU
KVM --> K_MMU
KVM --> LK
K_CPU --> CPU
K_MMU --> MEM
LK --> CPU
LK --> MEM
Q_DEV --> DEV| 层 | 组件 | 职责 |
|---|---|---|
| 用户态 | QEMU | 设备模拟(磁盘/网卡/GPU/USB)、VM 生命周期管理、Guest 内存分配 |
| 内核态 | KVM (kvm.ko + kvm_intel.ko/kvm_amd.ko) |
CPU 虚拟化(VMX/SVM)、内存虚拟化(EPT/NPT)、虚拟设备中断注入 |
| 硬件 | Intel VT-x / AMD-V | 提供 VMX root/non-root 模式、硬件加速页表遍历 |
2.2 通信机制:/dev/kvm 与 ioctl()
KVM 通过字符设备 /dev/kvm 向用户态暴露接口。QEMU 与 KVM 的控制接口以文件描述符和 ioctl() 为主,并使用 mmap 共享运行状态;现代 I/O 路径还可涉及 ioeventfd、irqfd 与 vhost。
QEMU/KVM 交互流程:
1. 打开设备:
fd_kvm = open("/dev/kvm", O_RDWR)
2. 创建虚拟机:
fd_vm = ioctl(fd_kvm, KVM_CREATE_VM, 0)
// 每个 fd_vm 代表一个独立的虚拟机实例
3. 分配 Guest 内存:
ioctl(fd_vm, KVM_SET_USER_MEMORY_REGION, &mem)
// KVM 将连片的 Host 物理内存映射到 Guest 物理地址空间
4. 创建虚拟 CPU:
fd_vcpu = ioctl(fd_vm, KVM_CREATE_VCPU, vcpu_id)
// 每个 VCPU 有独立的 fd_vcpu
5. 内存映射 VCPU 运行区域:
kvm_run = mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_SHARED, fd_vcpu, 0)
// 这个共享内存区用于 KVM 在 VM Exit 时写入退出原因
6. 主循环(每个 VCPU 一个线程):
while (running) {
ioctl(fd_vcpu, KVM_RUN, 0) // 阻塞线程,CPU 进入 Guest 模式
switch (kvm_run->exit_reason) { // VM Exit 后检查退出原因
case KVM_EXIT_IO: // I/O 指令模拟(磁盘/网络等)
handle_io(kvm_run);
break;
case KVM_EXIT_MMIO: // MMIO 访问
handle_mmio(kvm_run);
break;
case KVM_EXIT_SHUTDOWN: // Guest 关机
running = false;
break;
}
}2.3 VM Entry/Exit 流程(Intel VT-x 为例)
Intel VT-x 引入两种 CPU 模式:
- VMX Root Mode:Hypervisor(KVM)运行的模式。可以执行
VMLAUNCH/VMRESUME指令进入 Guest。 - VMX Non-Root Mode:Guest VM 运行的模式。当遇到敏感指令或事件时,CPU 自动触发 VM Exit 回到 Root Mode。
Host User (QEMU) Host Kernel (KVM) Hardware (Guest)
───────────────── ───────────────── ────────────────
ioctl(KVM_RUN)
│ │
└──────────────────────────────►│
│ 上下文保存 (Host → VMCS)
│ VMLAUNCH / VMRESUME
│────────────────────────► Guest Native 执行
│ (VMX Non-Root)
│
│ ◄────────────────────── VM Exit
│ (EPT Violation /
│ I/O Instruction /
│ External Interrupt)
│
│ 检查 exit_reason
│ ┌─ 可在内核处理 → 直接恢复
│ └─ 需用户态处理 → 返回 QEMU
◄───────────────────────────────┘
检查 kvm_run->exit_reason
设备模拟 / I/O 处理
→ 下次 ioctl(KVM_RUN)
VMCS (Virtual Machine Control Structure) 是这一机制的核心数据结构,由 KVM 在内核空间维护。它保存了 Host 状态和 Guest 状态的完整上下文(控制寄存器、段寄存器、MSR 等),QEMU 用户态不能直接访问 VMCS。
2.4 内存虚拟化:EPT/NPT
内存虚拟化有两条路径:
| 技术 | 说明 | 性能 |
|---|---|---|
| 影子页表 (Shadow Page Tables) | KVM 维护一份 Guest VA -> Host PA 的影子转换表,拦截 Guest 页表修改 | 中等,有额外维护开销 |
| EPT (Intel) / NPT (AMD) | CPU 硬件直接支持两层页表遍历:GVA -> GPA(Guest 页表)-> HPA(EPT/NPT 页表) | 接近裸金属,减少 VM Exit |
EPT/NPT 是 KVM 性能接近原生的关键。它消除了 Guest 页表修改触发的 VM Exit —— Guest 可以像原生系统一样修改自己的页表,硬件级的两层地址翻译在后台透明完成。
2.5 QEMU 的两种工作模式
# 模式 1:QEMU + KVM(硬件加速,接近原生性能)
qemu-system-x86_64 \
-enable-kvm \
-cpu host \
-m 4096 \
-drive file=disk.qcow2,format=qcow2 \
-netdev user,id=net0 \
-device virtio-net,netdev=net0
# 模式 2:QEMU 纯模拟(无硬件加速,非常慢)
qemu-system-aarch64 \
-M virt \
-cpu cortex-a57 \
-m 2048 \
-drive file=arm64-disk.qcow2,format=qcow2
# 注意:没有 -enable-kvm,因为这是跨架构模拟QEMU 纯模拟的价值 QEMU 的 TCG 可跨指令集模拟系统,例如 x86 宿主模拟 ARM。它不使用同架构 KVM 加速,性能差异需要按实际负载测量;这类系统模拟适用于嵌入式开发、逆向分析与固件测试。
2.6 重要内核模块
x86 宿主选择与 CPU 匹配的模块;不要在一台机器上同时执行 Intel 与 AMD 示例。nested=1 是否必要依内核默认值而定;ignore_msrs=1 是兼容性调试选项,会掩盖 MSR 问题,不是通用调优默认值。
# 架构无关基础模块(必须)
kvm.ko # KVM 核心框架
# 架构相关模块(二选一)
kvm_intel.ko # Intel VT-x 支持
kvm_amd.ko # AMD-V/SVM 支持
# 内核参数(可选调优)
modprobe kvm_intel nested=1 # 启用嵌套虚拟化(在 VM 内再跑 KVM)
# 历史兼容性调试示例;诊断未知 MSR 后才考虑,不作为默认:
# modprobe kvm ignore_msrs=13. libvirt:统一管理抽象层#
3.1 libvirt 解决了什么问题
直接使用 QEMU 命令行管理虚拟机在规模稍大时就会遇到严重问题:
# 一个生产环境虚拟机可能需要 30+ 个命令行参数
qemu-system-x86_64 -name guest=prod-db-01 \
-machine pc-q35-7.2 -accel kvm -cpu host -smp 8 \
-m 16384 -mem-prealloc -overcommit mem-lock=on \
-numa node,nodeid=0,cpus=0-3 -numa node,nodeid=1,cpus=4-7 \
-drive file=/var/lib/libvirt/images/db.qcow2,format=qcow2,if=none,id=drive0 \
-device virtio-blk-pci,drive=drive0,bootindex=1 \
-netdev tap,id=net0,ifname=vnet0,script=no,downscript=no \
-device virtio-net-pci,netdev=net0,mac=<GENERATED_MAC_ADDRESS> \
-vnc 127.0.0.1:1 -monitor unix:/tmp/qemu-monitor.sock,server,nowait \
# ... 还有更多参数libvirt 的目标是为各类 Hypervisor 提供统一的管理接口,核心价值:
| 能力 | 说明 |
|---|---|
| XML 声明式配置 | VM 的所有参数定义在一个 XML 文件中,可版本控制、可审计、可迁移 |
| 统一 API | 同一个 virsh 命令管理 KVM、Xen、LXC、VMware,Hypervisor 类型对上层透明 |
| 守护进程管理 | virtqemud 负责 VM 生命周期,自动启动/停止/重启 |
| 网络与存储池 | 统一管理虚拟网络(NAT/桥接)、存储池(LVM/ZFS/Ceph/目录) |
| 安全隔离 | 与 SELinux/sVirt 深度集成,每个 VM 有独立的安全标签 |
3.2 模块化守护进程架构(Modern libvirt)
传统 libvirt 使用单一的 libvirtd 守护进程处理所有功能。libvirt 同时提供单体与模块化守护进程部署;发行版是否采用模块化取决于包和服务配置,不能只按 libvirt 版本判断。模块化部署让各驱动运行在独立进程中:
| 守护进程 | 职责 | 相关 socket |
|---|---|---|
virtqemud |
QEMU/KVM VM 管理(核心) | /run/libvirt/virtqemud-sock |
virtxend |
Xen VM 管理 | /run/libvirt/virtxend-sock |
virtlxcd |
LXC 容器管理 | /run/libvirt/virtlxcd-sock |
virtnetworkd |
虚拟网络管理 | /run/libvirt/virtnetworkd-sock |
virtstoraged |
存储池/卷管理 | /run/libvirt/virtstoraged-sock |
virtnodedevd |
物理设备管理(PCI/USB) | /run/libvirt/virtnodedevd-sock |
virtsecretd |
Secret/凭据管理 | /run/libvirt/virtsecretd-sock |
virtnwfilterd |
网络过滤器管理 | /run/libvirt/virtnwfilterd-sock |
virtproxyd |
远程连接代理 | /run/libvirt/virtproxyd-sock |
virtlockd |
资源锁管理 | /run/libvirt/virtlockd-sock |
virtlogd |
VM 控制台日志 | /run/libvirt/virtlogd-sock |
模块化架构的优势:
- 安全隔离:每个守护进程有独立的攻击面。缩小共享进程范围,但共享权限、宿主资源和网络仍会形成交叉影响,不能保证 VM 不受影响。
- 独立重启:QEMU 进程独立,管理 daemon 的重启通常不会关掉客体,但管理操作、连接和进行中的作业可能受影响。
- 按需安装:容器化环境可以只安装
libvirt-daemon-driver-qemu,不需要全套依赖。 - Socket 激活:systemd 管理 socket,守护进程按需启动,降低空闲服务开销。
兼容性过渡 许多发行版仍然提供
libvirtd作为兼容选项。检查你的系统使用哪种模式:systemctl status libvirtd virtqemud | head -4
3.3 连接 URI
libvirt 通过 URI 指定要连接的目标 Hypervisor:
# 本地系统级管理连接(通过授权访问;daemon 形态取决于宿主)
virsh -c qemu:///system list --all
# 本地用户会话连接(用户权限,无需 root)
virsh -c qemu:///session list --all
# 远程连接(SSH 隧道)
virsh -c qemu+ssh://user@server.example.com/system list --all
# 远程连接(TLS 加密)
virsh -c qemu+tls://server.example.com/system list --all
# 设置默认 URI(避免每次输入 -c)
export LIBVIRT_DEFAULT_URI="qemu:///system"| URI 方案 | 场景 | 说明 |
|---|---|---|
qemu:///system |
服务器/数据中心 | 系统级管理连接;QEMU 运行身份由发行版与 qemu.conf 决定 |
qemu:///session |
桌面/开发 | 用户权限,VM 作为普通用户进程运行 |
qemu+ssh://host/system |
远程管理 | SSH 隧道,开箱即用,无需额外证书 |
qemu+tls://host/system |
企业部署 | TLS 双向认证,适合多管理员环境 |
3.4 virsh:命令行管理工具
# 列出所有 VM(包括未运行的)
virsh list --all
# 启动/关机
virsh start prod-db-01
virsh shutdown prod-db-01 # 优雅关机(发送 ACPI 信号)
virsh destroy prod-db-01 # 强制断电(相当于拔电源)
# 查看 VM 的 libvirt XML 配置
virsh dumpxml prod-db-01
virsh edit prod-db-01 # 在线编辑 XML(有语法校验)
# 控制台连接
virsh console prod-db-01 # 串口控制台(需要 Guest 配置 serial console)
# 资源信息
virsh dominfo prod-db-01 # VM 概览信息
virsh domstats prod-db-01 # CPU/内存/磁盘/网络统计
virsh vcpuinfo prod-db-01 # VCPU 到物理 CPU 的绑定关系4. virt-manager:图形化管理前端#
4.1 概述
virt-manager 是一个基于 GTK 的桌面应用程序,通过 libvirt 协议管理 KVM/Xen/LXC VM。它适合工作站和个人使用场景,在生产服务器的"紧急手动操作"时也很实用。
核心功能:
- VM 创建向导:图形化配置 CPU、内存、磁盘、网络,最终生成 libvirt XML
- 硬件热插拔:在线添加/移除虚拟磁盘、网卡(需要 Guest 支持)
- SPICE/VNC 控制台:内置远程桌面连接,支持剪贴板共享和 USB 重定向
- 快照管理:创建、恢复、删除 VM 快照(内部快照基于 qcow2,支持程度取决于磁盘格式、固件、TPM 与当前软件版本;快照不等于备份)
- 性能监控:实时 CPU 使用率、内存占用、磁盘/网络 I/O 曲线
4.2 辅助工具
| 工具 | 用途 |
|---|---|
| virt-viewer | 轻量级 SPICE/VNC 客户端,连接 VM 控制台而不启动完整的 virt-manager |
| virt-install | 命令行 VM 创建工具,适合脚本化/自动化部署 |
| virt-clone | 克隆现有 VM(自动处理 MAC 地址、磁盘镜像等冲突项) |
| virt-sysprep | 重置/清理 VM 镜像(删除 SSH host key、machine ID、日志等)用于模板化部署 |
| virt-builder | 快速构建 VM 镜像(类似 Dockerfile 的构建过程) |
| Cockpit-machines | Red Hat 推出的 Web 管理界面,通过 Cockpit 插件提供 VM 管理功能 |
4.3 自动化示例:virt-install
virt-install \
--name demo-vm \
--vcpus 2 \
--memory 2048 \
--disk size=20,format=qcow2,bus=virtio \
--network network=default,model=virtio \
--graphics spice \
--cdrom /path/to/ubuntu-24.04-server.iso \
--os-variant ubuntu24.04 \
--autostart
# 参数说明:
# --disk bus=virtio 使用 virtio 块设备,性能远优于 IDE/SATA 模拟
# --network model=virtio 使用 virtio 网络驱动,同样有更好的性能
# --os-variant 告诉 libvirt Guest OS 类型,以便自动选择最佳默认值
# --autostart 随 Host 启动时自动启动此 VM5. 虚拟化方案对比#
5.1 Hypervisor 横向对比
下表概括设计取向;性能、热迁移和快照支持均取决于版本、配置与负载。KVM 的宿主内核是 Linux,不能将表中的客户机 OS 支持理解为 KVM 可作为 Windows 宿主内核模块。容器共享宿主内核,CRIU 等迁移机制也有兼容性限制。
| 特性 | KVM/QEMU | VirtualBox | VMware Workstation | Xen | Hyper-V |
|---|---|---|---|---|---|
| 类型 | Type-1 (混合) | Type-2 | Type-2 | Type-1 | Type-1 |
| 性能 | 接近原生 | 中等 | 接近原生 | 接近原生 | 接近原生 |
| GPU Passthrough | 支持 (VFIO) | 有限 | 有限 | 支持 | 支持 (DDA) |
| 开源 | 是 (GPLv2) | 是 (GPLv2) | 否 (商业) | 是 (GPLv2) | 否 (商业) |
| Linux 集成度 | 内核主线 | 内核模块 (DKMS) | 内核模块 (DKMS) | 内核主线 (dom0) | 无 Linux 版本 |
| 学习曲线 | 中-高 | 低 | 低 | 高 | 中 |
| 管理工具 | libvirt/virsh/virt-manager | VBoxManage/GUI | VMware UI/vmrun | xl/xm/XAPI | Hyper-V Manager/SCVMM |
| 嵌套虚拟化 | 支持 | 支持 | 支持 | 实验性 | 支持 |
| 实时迁移 | 支持 | 不支持 | 不支持 | 支持 | 支持 |
5.2 KVM vs 容器(Docker/Podman/LXC)
这是最常见的选型问题。两者并非替代关系,而是互补关系。
| 维度 | KVM 虚拟机 | 容器 (Podman/Docker) |
|---|---|---|
| 隔离层级 | 完整内核隔离(每个 VM 有自己独立的 Kernel) | 共享 Host Kernel(namespace + cgroup 隔离) |
| 启动时间 | 秒级(5-30s) | 毫秒级(< 1s) |
| 内存开销 | 中等(每个 VM ~200-500MB 基础开销) | 极低(容器共享 Host Kernel,无额外内核内存) |
| 磁盘空间 | 较大(需要完整 OS 镜像,GB 级) | 极小(分层镜像,MB 级增量) |
| 不同 OS | 支持不同客户机内核(如 Linux 宿主上的 Windows 客体) | 不支持(必须与 Host 相同 Kernel) |
| 不同 Kernel 版本 | 支持(Guest 可以有不同的 Kernel 版本) | 不支持(共享 Host Kernel) |
| GPU Passthrough | 支持(VFIO,可用于游戏/AI 训练) | 支持有限(GPU 设备插件,但不支持完整独占) |
| 安全隔离 | 硬件级(借助 VT-x/AMD-V) | 内核特性级(seccomp/SELinux/user namespace) |
| 实时迁移 | 支持(Live Migration) | 不支持容器本身(可通过 Orchestrator 调度实现) |
| 典型场景 | 多租户隔离、不同 OS、桌面虚拟化、GPU 计算 | 微服务、CI/CD、开发环境、应用打包 |
选型原则
用 KVM 当:
- 需要跑不同操作系统(Linux + Windows + FreeBSD 混布)
- 需要强安全隔离(多租户公有云场景)
- 需要完整硬件独占(GPU Passthrough 做 AI 训练/游戏虚拟机)
- 需要运行非特权容器的独立 Docker/Podman 环境(KVM 里跑容器)
用容器当:
- 部署微服务/应用(快速启停、版本管理、CI/CD 集成)
- 需要极高密度(一台机器跑几百个实例)
- 依赖 Host 设备/硬件(直接用 Host 的 GPU、FPGA、RDMA)
常见组合:KVM + 容器 一种常见部署方式是 VM 提供不同内核和租户边界,容器在 VM 内运行应用。不能据此认定所有公有云都使用 KVM;不同平台会采用不同 hypervisor,例如 Azure 的虚拟化基础不能归为 KVM。
5.3 KVM 在云计算中的地位
KVM 是 Linux 云基础设施的绝对主力:
| 云平台 | 底层 Hypervisor | 说明 |
|---|---|---|
| Google Cloud | KVM (开源) | Google 是 KVM 最初的主要贡献者之一 |
| AWS Nitro | KVM (定制版) | AWS 在 KVM 基础上自研 Nitro 卡卸载 I/O |
| OpenStack | KVM (默认) | OpenStack Nova 默认使用 libvirt/KVM 驱动 |
| Proxmox VE | KVM + LXC | 开源虚拟化管理平台,KVM 做 VM,LXC 做容器 |
| oVirt / RHV | KVM | Red Hat 的企业虚拟化方案,对标 VMware vSphere |
| Apache CloudStack | KVM | 支持多种 Hypervisor,但 KVM 最常用 |
小结 KVM 不是"一个软件",而是一个分层协作的虚拟化栈:
- KVM 内核模块:提供 CPU/内存硬件加速
- QEMU:提供设备模拟和平台建模
- libvirt:提供统一管理 API 和工具链
- libguestfs/virt- 工具*:提供镜像操作和自动化能力
理解这四层各自的责任边界,是掌握 KVM 虚拟化体系的关键。
参考与延伸
根据技术笔记重新整理,示例使用通用名称。