OFFSET偏移
← 文章目录OFFSET / FIELD NOTESNO. 135

KVM、QEMU 与 libvirt 的职责边界

从硬件虚拟化、KVM API 到 QEMU 设备模型,建立理解管理栈的基础。

所在专题KVM 宿主与管理基础 ↗
约 32 分钟阅读开始阅读

命令与 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=1

3. 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 启动时自动启动此 VM

5. 虚拟化方案对比#

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 虚拟化体系的关键。



参考与延伸

  1. Linux KVM API ↗
  2. QEMU system emulation ↗
  3. libvirt daemon 部署 ↗
  4. libvirt URI ↗

根据技术笔记重新整理,示例使用通用名称。

沿专题继续阅读

KVM 宿主与管理基础

  1. 01KVM、QEMU 与 libvirt 的职责边界
  2. 02KVM 宿主安装、权限与网络准备
  3. 03用 virsh 管理域、存储、网络与恢复
  4. 04virt-manager 创建、硬件面板与远程控制
CONTINUE READING / 下一篇KVM 宿主安装、权限与网络准备

逐项检查宿主能力、发行版组件、管理授权和默认网络的实际状态。