课时2 虚拟化技术概述
对资源的抽象：
- 进程级虚拟化——应用层面抽象（如JVM）
- 系统虚拟化——平台层面抽象（虚拟机）
注意：本文讨论的是系统虚拟化，而不是进程级虚拟化。
虚拟化技术分类：
全虚拟化
硬件辅助虚拟化
基于二进制翻译等
半虚拟化（需要Guest OS的支持）
Hypervisor (VMM)
- Type 1：硬件之上直接运行Hypervisor
- Type 2：硬件之上运行Host OS并在内核中包含Hypervisor的功能
设计标准
Hypervisor：
必须能够控制硬件资源（CPU、内存、IO等）
必须有效隔离客户机（免受客户机的威胁）
多客户机之间强隔离
虚拟机：
等价性（硬件资源的等价性）
高效性（emulator不够高效，不被称为虚拟机）
常见的Hypervisor
- Xen - 剑桥大学 2002
亚马逊、rackspace、阿里云
- KVM - 以色列 2007
基于Linux内核
Hyper-v - 微软 2006
VMware ESX Server（高端服务器）
VMware workspace (工作站）
VirtualBox（PC上常用的虚拟化技术）
课时3 CPU虚拟化技术
CPU虚拟化：
- 二进制翻译（早期x86技术不支持虚拟化）
扫描Guest OS指令，对敏感指令进行替换；实现复杂，效率低。
- 半虚拟化（修改Guest OS中的敏感指令）
不需要扫描Guest OS指令，效率很高。
- 硬件辅助虚拟化
CPU厂商从硬件上支持虚拟化指令。
课时4 内存虚拟化技术
内存虚拟化挑战：
操作系统要求内存从0开始
操作系统要求内存地址连续
它的好处在于：低段内存连续、管理更高效、使用superTLBS加速访问效率
内存重映射技术
MMU（内存管理单元）虚拟化技术：
Direct page table 直接页表
Virtual TLB 虚拟TLB
Shadow page table 影子页表
Extended page table 硬件扩展页表
Direct page table
通过修改内核使Guest和Hypervisor共享同一张页表，使用段保护的方式对地址空间分段，让Guest无法访问Hypervisor的空间。这种技术广泛应用于XenLinux32，因为无需切换页表而相当高效，但安全性必须通过审计保证，且不支持Windows。
Virtual TLB
当Guest访问虚拟地址时触发page fault，Hypervisor通过分析得知是Guest的正常请求，于是将其翻译为Hypervisor的内存地址。该实现方案简单，但因为它只能缓存访问过的虚拟地址，因此效率非常低。
Shadow page table
在Guest内部有一张页表的同时，在Hypervisor中为其建立一张对应的转换表，即影子页表。影子页表的建立过程相对复杂（Guest访问虚拟内存，引发缺页异常，Hypervisor捕获并查询Guest中的页表，最终将Guest到Hypervisor的地址转换关系放入影子页表中）。该实现方案无需修改内核，但效率较低（相对物理机而言，XenLinux32的转换效率为84%左右，而XenLinux64仅为65%左右）。
Extend page table
CPU厂商引入硬件支持，完成虚拟机内存到物理机内存的转换，整个过程无需Hypervisor介入。而Hypervisor唯一需要做的就是在创建虚拟机时，将地址的映射关系放入CPU的某个寄存器当中。该实现方案的效率极高（相对物理机而言，使用4K页的转换效率可达95%以上，而使用2M页可达98%以上）。
课时5 IO虚拟化技术
I/O设备的工作原理：
- 硬件设备的中断请求
- CPU与内存的寄存器访问
- 设备与内存的DMA
I/O虚拟化的实现方式
软件模拟
Hypervisor通过捕获访问，然后解码并进行模拟。这种方式的效率很低，并且仅出现在早期的虚拟化中。
半虚拟化（PV）
重新定义I/O架构，例如Xen引入split diver，通过共享内存交换数据，摒弃了寄存器和DMA的操作方式，因此效率很高，唯一的不足是软件复杂度较高。采用PV虚拟化的I/O解决方案大量出现于商业级虚拟化软件中，例如Xen和KVM。
设备直通（VT-d + SRIOV）
CPU厂商通过在北桥芯片中加入VT-d技术，解决中断及DMA的remapping（重映射）问题，联合I/O设备对SRIOV技术的支持，解决物理设备独占访问的问题，最终使得I/O虚拟化的大部分工作由硬件完成，提高了效率并且降低了软件复杂度。
课时6 开源虚拟化项目
Xen
Xen起源于2002年剑桥大学的开源项目，2003年发布Xen2.0支持PV，2006年发布Xen3.0支持PVHVM，后来被Citrix以5亿美元收购，目前Xen仍处于研发状态，最新的Xen 4.6支持PVH。
Xen的PV模式，需要修改Guest OS内核，将所有的I/O，中断等重新定义，形成与x86完全不同的架构。而Xen的HVM模式，借助CPU的硬件辅助（VT-x），将Hypervisor运行在Ring0，Guest Kernel运行在Ring1上。HVM无需修改Guest OS内核。
Xen还提供了另外一些技术：用于挂载PV驱动的Xen Bus，还有用于信息存储和交换的Xen Store。
Xen对于I/O设备的支持包括软件模拟、半虚拟化（PV）和设备直通。
Xen的商业化云平台包括：亚马逊AWS、阿里云等。
KVM
KVM通过在Linux内核中加入一个模块，把Linux内核扩展成为Hypervisor。KVM最早由以色列的一家公司于2007年创建并引入Linux内核。它依赖于VT技术，最初仅支持x86架构，后来被RedHat以1亿美元收购。
KVM基于Linux内核开发而来，依赖Intel VMX或AMD SVM技术，完成CPU和内存的虚拟化，借助what I/O架构实现I/O虚拟化。此外，KVM还通过Para-virtualized spinlocks解决自旋锁的性能损失问题，通过Para-virtualized Timing解决时间虚拟化的问题，通过Para-virtualized Huge page降低内存虚拟化开销。
KVM的商业化云平台包括：Google GCE、阿里云ECS 2.0。
比较
Xen和KVM的共同点：借助硬件技术模拟CPU和内存，使用Qemu模拟非关键设备，通过PV增强虚拟化I/O的性能。
Xen和KVM的不同点：Xen是Type-1 Hypervisor而KVM是Type-2；Xen的软件复杂度（代码量）远大于KVM。