1.CPU 虚拟化
KVM 的虚拟化是需要 CPU 硬件支持的。
2.验证是否开启虚拟化
grep -E "vmx|svm" /proc/cpuinfo | wc -l
egrep -o "vmx|svw" /proc/cpuinfo (-o 输出符合的内容)
grep -E = egrep
如果有输出 vmx 或者 svm，就说明当前的 CPU 支持 KVM。CPU 厂商 Intel 和 AMD 都支持虚拟化了，除非是非常老的 CPU。
一个 KVM 虚机在宿主机中其实是一个 qemu-kvm 进程，与其他 Linux 进程一样被调度。 比如在我的实验机上运行的虚机 kvm1 在宿主机中 ps 能看到相应的进程。
这里有另一个知识点，即虚机的 vCPU 总数可以超过物理 CPU 数量，这个叫 CPU overcommit（超配）。
KVM 允许 overcommit，这个特性使得虚机能够充分利用宿主机的 CPU 资源，但前提是在同一时刻，不是所有的虚机都满负荷运行。
当然，如果每个虚机都很忙，反而会影响整体性能，所以在使用 overcommit 的时候，需要对虚机的负载情况有所了解，需要测试
2.内存虚拟化
KVM 通过内存虚拟化共享物理系统内存，动态分配给虚拟机。
为了在一台机器上运行多个虚拟机，KVM 需要实现 VA（虚拟内存） -> PA（物理内存） -> MA（机器内存）之间的地址转换。
虚机 OS 控制虚拟地址到客户内存物理地址的映射 （VA -> PA），但是虚机 OS 不能直接访问实际机器内存，因此 KVM 需要负责映射客户物理内存到实际机器内存 （PA -> MA）3.
3.KVM 存储虚拟化
1)目录类型的 Storage Pool
文件目录是最常用的 Storage Pool (储存池)类型。KVM 将宿主机目录 /var/lib/libvirt/images/ 作为默认的 Storage Pool。
那么 Volume 是什么呢？
答案就是该目录下面的文件了，一个文件就是一个 Volume
那 KVM 是怎么知道要把 /var/lib/libvirt/images 这个目录当做默认 Storage Pool 的呢？
实际上 KVM 所有可以使用的 Storage Pool 都定义在宿主机的 /etc/libvirt/storage 目录下，每个 Pool 一个 xml 文件，默认有一个 default.xml
注意：Storage Pool 的类型是 “dir”，目录的路径就是 /var/lib/libvirt/images
使用文件做 Volume 有很多优点：存储方便、移植性好、可复制、可远程访问。 前面几个优点都很好理解，这里对“可远程访问”多解释一下。
远程访问的意思是镜像文件不一定都放置到宿主机本地文件系统中，也可以存储在通过网络连接的远程文件系统，比如 NFS，或者是分布式文件系统中，比如 GlusterFS。
这样镜像文件就可以在多个宿主机之间共享，便于虚机在不同宿主机之间做 Live Migration(实时迁移)；如果是分布式文件系统，多副本的特性还可以保证镜像文件的高可用。
KVM 支持多种 Volume 文件格式，在添加 Volume 时可以选择。
raw 是默认格式，即原始磁盘镜像格式，移植性好，性能好，但大小固定，不能节省磁盘空间。
qcow2 是推荐使用的格式，cow 表示 copy on write，能够节省磁盘空间，支持 AES 加密，支持 zlib 压缩，支持多快照，功能很多。
vmdk 是 VMWare 的虚拟磁盘格式，也就是说 VMWare 虚机可以直接在 KVM上 运行。
4.LVM 类型的 Storage Pool
不仅一个文件可以分配给客户机作为虚拟磁盘，宿主机上 VG 中的 LV 也可以作为虚拟磁盘分配给虚拟机使用。
不过，LV 由于没有磁盘的 MBR 引导记录，不能作为虚拟机的启动盘，只能作为数据盘使用。
“MBR的意思是主引导记录，是传统分区类型，只支持一个硬盘上最多4个主分区，最大的缺点是不支持2TB以上硬盘容量，而GUID就是新兴的GPT方式，
支持的主分区数量没有限制；
MBR支持win7版本系统以下的32位和64位，而GUID支持win7版本以上的64位系统，不支持32位系统。”
LV 的优点是有较好的性能；不足的地方是管理和移动性方面不如镜像文件，而且不能通过网络远程使用。
5.其他类型的Storage Pool
KVM 还支持 iSCSI，Ceph 等多种类型的 Storage Pool，这里就不一一介绍了，最常用的就是目录类型