首页 > 代码库 > kvm-1

kvm-1

虚拟化:KVMvmwareopenvzxen

//国内用的最多的是KVMvmware

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

 

1.虚拟化技术与KVM

内容:CPU,内存,IO

虚拟化的标准:

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

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

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

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


早期的虚拟化:

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

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

 

X86平台的虚拟化:

1.特权级压缩:----完全虚拟化:仅从CPU的架构来说,使用trapemulate实现虚拟化 //早期的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技术 实现虚拟化 //二进制翻译


 技术分享

 


硬件:VMMring 0):guest os.(kernel)--ring 1 ring 2空闲:ring 3--APP

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

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

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

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

半虚拟化:

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

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

需要修改guest.Kernel

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

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

//VMMguest.kernel都运行在ring 0

//必须要修改内核

硬件辅助虚拟化:

Ring -1VMMhypervisor

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

Ring1ring 2空闲 //guest的内核不再需要修改

 

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

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

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

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

内存虚拟化//MMU,TLB

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

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

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

转化过程:

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

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

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

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

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

这个转化过程相当麻烦:

 因此:

Shadow MMU EPTAPT //intelAMDMMU

通过MMU转换的是GVA-GPA

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

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

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

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

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

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

 

 

I/O虚拟化

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

VMM的实现方式:

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

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

 

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

//可以把VMMhypervisor当做一个东西

    技术分享

 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,精简版的OSVMM

//

VMM:IO驱动有三种模式:

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

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

//依赖于外部OS

//自我提供特权域

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

IO虚拟化模型:

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

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

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

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

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

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

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

案例:

完全虚拟化:vmware workstation {type-II}kvmvirtual box

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

//type-I:硬件上是hypervisorhypervisor之上的guest-os

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

KVMkernel-based virtual Machine //不属于type-I,也不属于type-II

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

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

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

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

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

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

借助qemu实现IO模拟//qemu 可以模拟CPUmemoryIO

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

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

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

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

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

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

 

1.查看是否支持

Lsmod |grep kvm

Modprobe kvm  //KVM是通用,AMDintel

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

 

Qemu-kvm //专用于结合KVMqemu

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

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

KVMQumranet公司,生产的,2008.9月被redhat 大约1.07亿美元现金美金收购

2.KVM架构

技术分享

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

用户模式:包括{来宾模式,} //来宾模式:{来宾内核模式+来宾用户模式}

内核模式:

//VCPUKVM使用一个线程来事项guest访问CPU

3.KVM组件

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

创建虚拟机啊;

为虚拟机分配内存

读、写VCPU的寄存器

vcpu注入中断

运行vcpu

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

4.半虚拟化:virt-IO

红帽半虚拟化:virt-IO通过IBM等其他公司,做了半虚拟化,vmwarevirtual box都支持的半虚拟化技术:virIO

技术分享

 

半虚拟化:两段,前一段在guest上,后半段在hypervisor

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

半虚拟化的问题:

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

 

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

任务:openVZ的了解实现,安装

 


本文出自 “11246922” 博客,转载请与作者联系!

kvm-1