2. 虚拟化与KVM基础

在开始管理KVM虚拟机生命周期之前，必须先建立一张清晰的“技术地图”：虚拟化到底分几类，KVM处在哪一层，QEMU、libvirt各自扮演什么角色，内核模块与用户态组件如何协作。只有把这条链路理顺，后续创建、启动、迁移、销毁虚拟机时，遇到报错才能快速定位是内核层、设备模拟层还是管理接口层的问题。

一、虚拟化技术分类：从抽象层次理解

虚拟化按抽象对象不同，通常分为以下几类：

• 全虚拟化：Guest OS无需修改，敏感指令由Hypervisor动态捕获并模拟。KVM配合QEMU即属于此类，Guest认为自己运行在真实硬件上。
• 半虚拟化：Guest OS需修改内核，主动配合Hypervisor，典型如Xen PV。性能好但兼容性差。
• 硬件辅助虚拟化：依赖CPU指令集扩展，Intel VT-x与AMD-V提供根模式/非根模式，让敏感指令自动陷入Hypervisor，是全虚拟化高性能的基础。
• 操作系统级虚拟化：如LXC、Docker，共享同一内核，隔离的是进程与命名空间，不是完整硬件抽象。

KVM属于“硬件辅助全虚拟化”路线：它把Linux内核本身变成一个Hypervisor，借助VT-x/AMD-V实现CPU虚拟化，内存虚拟化由EPT/NPT完成，设备虚拟化则交给QEMU。

二、KVM架构原理：内核态与用户态的分工

KVM不是完整的Hypervisor，而是Linux内核中的一个模块。加载kvm.ko与kvm_intel.ko（或kvm_amd.ko）后，内核获得创建虚拟CPU、虚拟内存的能力。用户态通过/dev/kvm字符设备调用KVM_CREATE_VM、KVM_CREATE_VCPU、KVM_RUN等ioctl进入Guest执行；当Guest执行敏感指令或发生I/O时，CPU从非根模式退出到根模式，KVM处理后再返回用户态QEMU。

因此KVM的架构可以概括为：内核态KVM负责CPU与内存虚拟化，用户态QEMU负责设备模拟与虚拟机生命周期控制。两者通过ioctl和共享内存区域协作。

三、QEMU与libvirt的关系：管理接口与执行引擎

很多初学者会把QEMU和libvirt混为一谈。实际上：

• QEMU是虚拟机执行引擎，负责创建vCPU线程、模拟设备、加载Guest镜像。它可以直接用命令行启动，例如qemu-system-x86_64 -m 2048 -smp 2 -hda disk.qcow2。
• libvirt是管理抽象层，提供统一API、XML描述和virsh工具，屏蔽不同Hypervisor（KVM、Xen、QEMU）差异。它不直接模拟硬件，而是调用QEMU。

关系可以概括为：libvirt 管“怎么定义和调度”，QEMU 管“怎么执行和模拟”，KVM 管“怎么加速”。使用virsh define定义XML后，libvirt会生成对应的QEMU命令行并启动进程。

# 查看 libvirt 为某虚拟机生成的 QEMU 命令行
virsh domxml-to-native qemu-argv /etc/libvirt/qemu/vm01.xml

# 直接查看 QEMU 进程
ps -ef | grep qemu-kvm

# 查看 KVM 模块是否加载
lsmod | grep kvm
# kvm_intel             315392  0
# kvm                   831488  1 kvm_intel

四、KVM内核模块与用户态组件清单

五、典型场景与常见误区

场景：执行virsh start vm01后虚拟机无法启动。排查顺序应为：先确认lsmod | grep kvm模块是否加载，再检查/dev/kvm权限，然后查看/var/log/libvirt/qemu/vm01.log中QEMU报错，最后确认XML中磁盘路径与网络配置是否正确。这条链路正好对应“libvirt → QEMU → KVM → 硬件”的分层结构。