kvm-1

虚拟化：KVM，vmware，openvz，xen

//国内用的最多的是KVM，vmware

//国外大厂商用的最多的是openVZ,lxc和xen，因为这个性能要比KVM好的很多

1.虚拟化技术与KVM：

内容：CPU，内存，IO

虚拟化的标准：

1.等价执行，在虚拟机上执行的结果，要和在物理机上执行的结果一样

2.性能良好，guest的大多数指令，能够直接运行在cpu上，而不用翻译或者转换

3.安全隔离，任何一个虚拟机，不能关闭其他guest，除了xen的domain0，不能让一个虚拟机通过内存入侵到其他虚拟机中去，

//虚拟和模拟是不一样的

早期的虚拟化：

Trap：捕获guest的请求后，hypervisor捕获这个请求后，将其翻译成自己可以执行的指令，所以任何的guest指令都不能直接执行，都必须拿到hypervisor上处理后，才能执行

Emulate：模拟，大多的硬件都是以纯软件的方式提供给guest的

X86平台的虚拟化：

1.特权级压缩：----完全虚拟化：仅从CPU的架构来说，使用trap和emulate实现虚拟化 //早期的x86架构实现虚拟化比较困难//早期的x86使用内核必须运行在ring 0，但是guest 的也要运行在ring 0，
解决方法：

2.特权级别名，欺骗guest，你就在ring 0

3.地址空间压缩：VMM：虚拟机监视器，所有的guest-os所得到的的地址空间中，必须保留一部分为VMM使用// VMM的有些指令，监控功能是直接运行在guest-os上的

4.非特权敏感指令，有些指令敏感，需要隔离，

5.静默特权失败，x86的某些特权指令在执行失败以后不会返回错误，因此不能被VMM捕获

6.中断虚拟化，在guest中的{屏蔽中断和非屏蔽中断}，都应该由VMM进行，然而guest对特权资源的每次访问，都会触发处理器异常，需要VMM在两种模式之间来回切换

//中断虚拟化会导致性能降低

模拟：得到指令后，翻译为其他指令，得到相同的结果

虚拟：给你虚拟一个设备，当你要使用的时候，指令直接在物理主机上运行

B-T技术 实现虚拟化 //二进制翻译

硬件：VMM（ring 0）：guest os.(kernel)--ring 1 ：ring 2空闲：ring 3--APP

App运行非特权指令：直接在cpu上直接运行

特权指令：guest os会交给自己的内核，向VMM发送请求，

//例如使用shutdown指令，显然VMM是不允许guest关闭宿主机的，因此翻译指令让guest关机，vmm让gues认为自己是出于ring 0中，

CPU虚拟化：3种 //硬件辅助虚拟化

半虚拟化：

硬件由VMM直接执行，VMM运行在ring 0，guest os运行也在ring 0

Ring 2， ring1都是空闲的，app运行在ring 3上

需要修改guest.Kernel

//app直接运行在cpu上，加入guest os要运行特权指令，交给guest.kernel

//guest.kernel知道自己是虚拟的，直接调用vmm,使用hypyercall实现，调用hypercall实现

//VMM和guest.kernel都运行在ring 0

//必须要修改内核

硬件辅助虚拟化：

Ring -1：VMM，hypervisor，

Ring 0，guest os的内核 //ring0没有特权指令，

Ring1，ring 2空闲 //guest的内核不再需要修改

半虚拟化：gutst知道自己是虚拟的，需要修改内核

完全虚拟化：速度比较慢，性能相对比较差，全是虚拟的

硬件辅助虚拟化：guest也是完全虚拟化，//因为guest仍然不知道自己是被虚拟出来的

//内核不能修改的时候，只能使用完全虚拟化，硬件辅助虚拟化

内存虚拟化//MMU,TLB

X86为了实现进程隔离，和内存保护，早都已经实现了虚拟化//已经实现了物理地址到线性地址的转化

//这种转化依赖于MMU：硬件

进程使用的地址是线性地址：是虚拟的，需要转化为物理地址//这个对应关系放在  page table中

转化过程：

由CPU直接把地址{进程的虚拟地址}发送给MMU，MMU查找这个page table转换成物理地址

MMU还有一个作用：内存保护，任何时候，一个进程发送给MMU一个 自己并不属于的地址，它是访问不到的，因此在一定程度上实现了内存保护

MMU：负责VA-PA的转化，虚拟地址到物理地址----以及内存保护

虚拟化后地址需要转化三次：

GVA--GPA---HPA // 最后在真实的内存中运行

这个转化过程相当麻烦：

因此：

Shadow MMU EPT，APT //intel和AMD的MMU

通过MMU转换的是GVA-GPA，

进程需要转换的时候，cpu将地址分别给MMU和shadow MMU一份，这样线性地址就直接转换成了HA

Shadow：直接从GVA--HPA//一次转换成功，加速了访问

//一个MMU供实际使用，一个供虚拟转化

//MMU的转换速度 比较慢，为了加快速度，引入了TLB的机制//加速缓存命中率

但是guest a的TLB和guest b的TLB很有肯能会冲突，这样的话，TLB就没有意思了,而且很有可能会混淆导致故障或，泄露 //因此guest os在CPU上切换的时候，必须要清空TLB，

为了避免这种情况，tagged TLB //打标记的TLB，标记是哪一个guest-os的TLB

I/O虚拟化

IO速度本身就比较慢，如果虚拟一次后，

VMM的实现方式：

Type-I型：hypervisor运行在硬件上，各个OS都是虚拟机实例 //实例1是特权实例，其他都是guest

Hypervisor需要驱动各个硬件，需要为hypervisor提供驱动

Typ-II型：某一个OS运行在硬件上，在该OS上安装一个软件是VMM//

//可以把VMM和hypervisor当做一个东西

 Type-I               type-II

//xen只驱动内存和cpu，其他的驱动由domain 0 实现

//guest使用IO的时候，转发给domain 0，然后domain  0再次使用

假如使用纯软件的方式模拟出：SATA设备

IO完全虚拟化：//性能比较差

Guest os对该设备的访问过程：

1.Guest os的某个进程需要访问硬盘上的某个文件时，通过内核调用实现

2.内核调用该硬盘的驱动程序，去封装指令，发送给虚拟出来的接口 //第一次封装

3.但是这个接口在domain 0上只是一个文件，软件解码，解码完以后，提取内容，发起对本地文件的调用，

4.调用domain 0上的对应磁盘的驱动程序，最后封装起来，向硬件发送//再次封装

//软件模拟出来的设备通常都是比较通用的，容易驱动的

IO半虚拟化：

Domain 0直接做成调用，你一半，我一半，guest知道这是一个特殊设备，需要的驱动是domain 0上简化后的驱动，直接调用即可，前半段，guest完成，后半段domain 0完成

混合虚拟化：hybrid

有些IO半虚拟化，有些IO模拟，

Vmware  ESX  //自己提供了domain 0，精简版的OS，VMM

//

VMM:对IO驱动有三种模式：

1.自主VMM，IO由VMM自己提供驱动和控制台 //专用VMM，什么都是专用的

2.混合VMM，借助于外部OS提供驱动   //外部OS的驱动

//依赖于外部OS

//自我提供特权域

3.寄宿VMM；type-II//通过domain 0直接调用驱动，封装好的，我也知道

IO虚拟化模型：

1.纯模拟//软件模拟实现，完全，需要两次封装

2.半虚拟化//使用的时候，type-II，还要通过domain 0的后半段实现,驱动使用的是domain 0//的

3.透传//直接分配硬件，例如3个硬盘，guest1使用第一块，guest2使用第二块

//但是分配需要使用domain 0实现，但是真正使用的时候，不再通过domain 0

//假如只有一块硬盘，只有一个网卡的时候就有点难办了--因此

//出现了IOV的技术，改技术可以把多个物理硬件轮流给多个OS来使用，

//例如vmnet-0，vmnet-2就是多个网卡，可以直接使用，但是底层是轮流来调用//的

案例：

完全虚拟化：vmware workstation {type-II}，kvm，virtual box

半虚拟化：Xen，//type-I ,vmware-ESX {type-I},   //

//type-I：硬件上是hypervisor，hypervisor之上的guest-os

//type-II:host之上的guest-os

KVM：kernel-based virtual Machine //不属于type-I，也不属于type-II

//KVM实现了type-I的功能，又实现了type-II的特性

//KVM仅仅是linux内核的一个模块而已，OS安装好kvm之后，内核立马变成了hypervisor

//这个内核就可以直接创建虚拟机了

KVM装载进内核以后，内核可以虚拟CPU和内存，但无法虚拟IO

KVM装载进入内核之后，内核就会运行在ring -1上//硬件支持

使用软件模拟IO，KVM本身并不会虚拟IO设备

借助qemu实现IO模拟//qemu 可以模拟CPU，memory，IO

Qemu：创建并管理机的工具 //模拟器

CPU：底层cpu和虚拟的cpu架构可以不一样，但是性能差

//kqemu:使用qemu的二进制，kqemu是qemu的加速器,否则需要翻译

//qemu好像bug太多，因此应用场景不多见，不稳定

//可以认为KVM就是kqemu的替代产品

//kvm要求硬件必须支持虚拟化的

1.查看是否支持

Lsmod |grep kvm

Modprobe kvm  //KVM是通用，AMD和intel的

Ls /dev/kvm  //直接会在dev目录下建立一个kvm设备

Qemu-kvm //专用于结合KVM的qemu

Qemu可以独立使用，kvm为了结合KVM自己开发的

//没有KVMqemu可以独立生存，只不过性能不那么好，但是KVM就离不开qemu了，因为他要创建硬件

KVM是Qumranet公司，生产的，2008.9月被redhat 大约1.07亿美元现金美金收购

2.KVM架构

//借助于kvm的工作的那一部分叫做hypervisor，不借助于kvm内核工作的那一部分，仍然是一个内核

用户模式：包括{来宾模式，} //来宾模式：{来宾内核模式+来宾用户模式}

内核模式：

//VCPU：KVM使用一个线程来事项guest访问CPU

3.KVM组件

1./dev/kvm：管理虚拟机的设备节点，用户空间的程序可通过ioctl（）系统调用集成来完成虚拟机的创建启动管理工作，它是一个字符设备，其主要完成的操作包括，

创建虚拟机啊；

为虚拟机分配内存

读、写VCPU的寄存器

向vcpu注入中断

运行vcpu

2.qemu进程：工作于用户空间的组件，用于仿真PC机的I/O类硬件设备；

4.半虚拟化：virt-IO

红帽半虚拟化：virt-IO通过IBM等其他公司，做了半虚拟化，vmware，virtual box都支持的半虚拟化技术：virIO

半虚拟化：两段，前一段在guest上，后半段在hypervisor上

//常见组成：CPU完全虚拟化，IO半虚拟化，IO也可以使用完全虚拟化

半虚拟化的问题：

1.网卡半虚拟化，windows驱动不了，网卡，怎么办//，红帽直接为其提供了半虚拟化windows驱动

但是在IDC上，openvz使用的可能更多一点 ，不会对内核进行虚拟化，而是虚拟了多个用户空间，所以性能损失比较小，但是任何一个用户空间，加入直接把内核整挂了，那就大家都玩完，性能特别好

任务：openVZ的了解实现，安装