因为VMM (Virtual Machine Monitor) 掌控所有系统资源,因此VMM 握有整个内存资源,其负责页式内存管理,维护虚拟地址到机器地址的映射关系。因Guest OS本身亦有页式内存管理机制,则有VMM的整个系统就比正常系统多了一层映射:
- 虚拟地址(VA),指 Guest OS 提供给其应用程序使用的线性地址空间;
- 物理地址(PA),经 VMM 抽象的、虚拟机看到的伪物理地址;
- 机器地址(MA),真实的机器地址,即地址总线上出现的地址信号;
映射关系如下:Guest OS: PA = f(VA)、VMM: MA = g(PA)
VMM 维护一套页表,负责PA 到MA 的映射。Guest OS 维护一套页表,负责VA 到PA 的映射。实际运行时,用户程序访问VA1,经Guest OS 的页表转换得到PA1,再由VMM 介入,使用VMM 的页表将PA1 转换为MA1。
页表虚拟化技术原理:
普通 MMU只能完成一次虚拟地址到物理地址的映射,在虚拟机环境下,经过 MMU 转换所得到的“物理地址”并不是真正的机器地址。若需得到真正的机器地址,必须由VMM 介入,再经过一次映射才能得到总线上使用的机器地址。如果虚拟机的每个内存访问都需要VMM 介入,并由软件模拟地址转换的效率是很低下的,几乎不具有实际可用性,为实现虚拟地址到机器地址的高效转换,现普遍采用的思想是:由VMM根据映射f和g生成复合的映射fg,并直接将这个映射关系写入 MMU。当前采用的页表虚拟化方法主要是MMU类虚拟化(MMU Paravirtualization)和影子页表,后者已被内存的硬件辅助虚拟化技术所替代。
1、MMU virtualization
其基本原理是:当Guest OS创建一个新的页表时,会从它所维护的空闲内存中分配一个页面,并向VMM注册该页面,VMM会剥夺Guest OS对该页表的写权限,之后Guest OS对该页表的写操作都会陷入到VMM加以验证和转换。VMM会检查页表中的每一项,确保他们只映射了属于该虚拟机的机器页面,而且不得包含对页表页面的可写映射。后VMM会根据自己所维护的映射关系,将页表项中的物理地址替换为相应的机器地址,最后再把修改过的页表载入MMU。如此,MMU就可以根据修改过页表直接完成虚拟地址到机器地址的转换。
2、内存硬件辅助虚拟化
内存的硬件辅助虚拟化技术是用于替代虚拟化技术中软件实现的“影子页表”的一种硬件辅助虚拟化技术,其基本原理是:GVA(客户操作系统的虚拟地址)-> GPA(客户操作系统的物理地址)-> HPA(宿主操作系统的物理地址)两次地址转换都由CPU硬件自动完成(软件实现内存开销大、性能差)。以VT-x技术的页表扩充技术Extended Page Table(EPT)为例,首先VMM预先把客户机物理地址转换到机器地址的EPT页表设置到CPU中;其次客户机修改客户机页表无需VMM干预;最后,地址转换时,CPU自动查找两张页表完成客户机虚拟地址到机器地址的转换。使用内存的硬件辅助虚拟化技术,客户机运行过程中无需VMM干预,去除了大量软件开销,内存访问性能接近物理机。
你好,有个技术上的问题想请教一下。最近有个业务需求是对ovirt创建的虚拟机进行磁盘加密,以实现数据保护的作用。我尝试过重新编译了vdsm的storage部分源码,能够实现创建出qcow2格式的加密磁盘,但此时虚拟机无法正常启动,这个问题困扰了我很久,能给我指明一个方向吗,感激不尽!
目前qemu版本采用luks的加密方式,通过libvirt使用参考:
https://libvirt.org/formatstorageencryption.html#StorageEncryptionLuks
vdsm调的也是libvirt。
如果虚拟机分配了16G内存宿主机是直接分配16G还是虚拟机实际占用多少进行动态分配的?
给虚机分配内存时有个“保证的物理内存”,如果这个地方填的16G的话,那这个虚机实际占用就会是16G,如果“内存大小”填写的是16G,而“保证的物理内存”填的12G的话,那么就有4G的内存是动态分配使用的。
4.3版本的,查看配置没有生效。
VM主机配置
ovirt服务器内存为64G,现在创建了4台都为16G内存的虚拟机,4台虚拟机实际总共使用了20G的内存,为什么就不能再次创建和启动虚拟机了呢
4台16G的话已经到64G了呀,它这个是按已分配做的限制,不是根据实际占用的,想再建虚机的话可以开超分配,集群里面配,150% 200%都可以