云计算与KVM实践运用3

1.什么是KVM KVM的简史

KVM (全称是 Kernel-based Virtual Machine) 基于内核的虚拟机。前面提到的，是采用硬件虚拟化技术的全虚拟化解决方案，但是其究竟是归于1类机还是2类机一直具有争议。

ps：首先其基于kernel module的形式，与kernel融为一体，可认定为1类机，但其在逻辑上又受制于kernel ，资源管理均由kernel实现，又可认定为2类机。

由 Quramnet开发，该公司于 2008年被 Red Hat 收购。

它支持 x86 (32 and 64 位), s390, Powerpc 等 CPU。它从 Linux 2.6.20 起就作为一模块被包含在 Linux 内核中。它需要支持虚拟化扩展的CPU。它是完全开源的。官方网站：http://www.linux-kvm.org/page/Main_Page

KVM 是基于虚拟化扩展（Intel VT 或者 AMD-V）的 X86 硬件的开源的 Linux 原生的全虚拟化解决方案。KVM 中，虚拟机被实现为常规的 Linux 进程，由标准 Linux 调度程序进行调度；虚机的每个虚拟 CPU 被实现为一个常规的 Linux 进程。这使得 KVM 能够使用Linux 内核的已有功能。但是，KVM 本身不执行任何硬件模拟，需要客户空间程序通过 内核模块/dev/kvm 接口设置一个客户机虚拟服务器的地址空间，向它提供模拟的 I/O，并将它的视频显示映射回宿主的显示屏。目前这个应用程序是 QEMU。

Guest：客户机系统，包括CPU（vCPU）、内存、驱动（Console、网卡、I/O 设备驱动等），被 KVM 置于一种受限制的 CPU 模式下运行。

KVM：运行在内核空间，提供CPU 和内存的虚级化，以及客户机的 I/O 拦截。Guest 的 I/O被 KVM 拦截后，交给 QEMU 处理。

QEMU：修改过的为KVM虚机使用的QEMU代码，运行在用户空间，提供硬件I/O虚拟化，通过IOCTL /dev/kvm 设备和 KVM 交互。

KVM 是实现拦截虚机的 I/O 请求的原理：     现代 CPU 本身实现了对特殊指令的截获和重定向的硬件支持，甚至新硬件会提供额外的资源来帮助软件实现对关键硬件资源的虚拟化从而提高性能。以 X86 平台为例，支持虚拟化技术的 CPU  带有特别优化过的指令集来控制虚拟化过程。通过这些指令集，VMM 很容易将客户机置于一种受限制的模式下运行，一旦客户机试图访问物理资源，硬件会暂停客户机运行，将控制权交回给 VMM 处理。VMM 还可以利用硬件的虚级化增强机制，将客户机在受限模式下对一些特定资源的访问，完全由硬件重定向到 VMM 指定的虚拟资源，整个过程不需要暂停客户机的运行和 VMM 的参与。由于虚拟化硬件提供全新的架构，支持操作系统直接在上面运行，无需进行二进制转换，减少了相关的性能开销，极大简化了VMM的设计，使得VMM性能更加强大。从 2005 年开始，Intel 在其处理器产品线中推广 Intel Virtualization Technology 即 IntelVT 技术。

QEMU-KVM：   其实 QEMU 原本不是 KVM 的一部分，它自己就是一个纯软件实现的虚拟化系统，所以其性能低下。但是，QEMU 代码中包含整套的虚拟机实现，包括处理器虚拟化，内存虚拟化，以及 KVM需要使用到的虚拟设备模拟（网卡、显卡、存储控制器和硬盘等）。 为了简化代码，KVM 在 QEMU 的基础上做了修改。VM 运行期间，QEMU 会通过 KVM 模块提供的系统调用进入内核，由 KVM 负责将虚拟机置于处理的特殊模式运行。当虚机进行 I/O 操作时，KVM 会从上次系统调用出口处返回 QEMU，由 QEMU 来负责解析和模拟这些设备。   从 QEMU 角度看，也可以说是 QEMU 使用了 KVM 模块的虚拟化功能，为自己的虚机提供了硬件虚拟化加速。除此以外，虚机的配置和创建、虚机运行所依赖的虚拟设备、虚机运行时的用户环境和交互，以及一些虚机的特定技术比如动态迁移，都是 QEMU 自己实现的。  

KVM：     KVM 内核模块在运行时按需加载进入内核空间运行。KVM 本身不执行任何设备模拟，需要 QEMU 通过 /dev/kvm 接口设置一个 GUEST OS 的地址空间，向它提供模拟的 I/O 设备，并将它的视频显示映射回宿主机的显示屏。它是KVM 虚机的核心部分，其主要功能是初始化 CPU 硬件，打开虚拟化模式，然后将虚拟客户机运行在虚拟机模式下，并对虚机的运行提供一定的支持。以在 Intel 上运行为例，KVM 模块被加载的时候，它：

1. 首先初始化内部的数据结构；
2. 做好准备后，KVM 模块检测当前的 CPU，然后打开 CPU 控制及存取 CR4 的虚拟化模式开关，并通过执行 VMXON 指令将宿主操作系统置于虚拟化模式的根模式；
3. 最后，KVM 模块创建特殊设备文件 /dev/kvm 并等待来自用户空间的指令。

      接下来的虚机的创建和运行将是 QEMU 和 KVM 相互配合的过程。两者的通信接口主要是一系列针对特殊设备文件 /dev/kvm 的 IOCTL 调用。其中最重要的是创建虚机。它可以理解成KVM 为了某个特定的虚机创建对应的内核数据结构，同时，KVM 返回一个文件句柄来代表所创建的虚机。       针对该句柄的调用可以对虚机做相应地管理，比如创建用户空间虚拟地址和客户机物理地址、真实物理地址之间的映射关系，再比如创建多个 vCPU。KVM 为每一个 vCPU 生成对应的文件句柄，对其相应地 IOCTL 调用，就可以对vCPU进行管理。其中最重要的就是“执行虚拟处理器”。通过它，虚机在 KVM 的支持下，被置于虚拟化模式的非根模式下，开始执行二进制指令。在非根模式下，所有敏感的二进制指令都被CPU捕捉到，CPU 在保存现场之后自动切换到根模式，由 KVM 决定如何处理。       除了 CPU 的虚拟化，内存虚拟化也由 KVM 实现。实际上，内存虚拟化往往是一个虚机实现中最复杂的部分。CPU 中的内存管理单元 MMU 是通过页表的形式将程序运行的虚拟地址转换成实际物理地址。在虚拟机模式下，MMU 的页表则必须在一次查询的时候完成两次地址转换。因为除了将客户机程序的虚拟地址转换了客户机的物理地址外，还要将客户机物理地址转化成真实物理地址。 

功能概述

1.内存管理

内存也需要硬件模块VT-x与VT-d 的支持

      NPT (Nested PageTables)AMD称为NPT

      GVA (Guest Virtual Address) 客户机虚拟地址 guest

      GPA (Guest Physical Address) 客户机物理地址

      HPV (Host Physical Address) 客户机物理地址 Hypervisor

      EPT (Extended Page Tables)属于Intel的二代硬件虚拟化技术，针对内存管理单元(MMU)的虚拟化扩展。EPT降低了内存虚拟化的难度(影子页表)也提升了内存虚拟化的性能。从基于Intel的Nehalem架构的平台开始，EPT作为CPU的一个特性加入到CPU硬件中去了。

      一个机子对应一个影子页表，记录了客户机虚拟地址与客户机逻辑地址、客户机物理地址的对应关系——虚拟机的物理地址对应着物理机的逻辑地址，物理机逻辑地址对应着物理机的物理地址。所以在没有EPT之前，内存的压力很大，既要存储影子页表又要管理这些影子页表。为了解决内存压力就产生了EPT，1个EPT页表=N个影子页表。CPU用EPT记录影子页表的信息，CR3会根据EPT表的信息把交互信息直接交给内核处理，这样内存的管理压力与存储压力就缓解了许多。

      由于影子页表的存在，如果物理机内存只有32G的话，那只能安装3个8G内存的虚拟机，剩下的空间要留给内存进行管理以及其他工作。

VPID (VirtualProcessor Identifiers)虚拟处理器标识,提升实时迁移的效率,同时节省实时迁移的开销,提高速度,降低延迟。在进行虚拟机迁移时，不仅要保证CPU型号一致，还要保证内存的编号与新物理机中的虚拟机编号的内存不冲突，这是VPID就发挥了作用。

      TLB (translation lookaside buffer)旁路转换缓冲，或称为页表缓冲；里面存放的是一些页表文件（虚拟地址到物理地址的转换表）。

#grep  ept  /proc/cpuinfo

#grep  vpid   /proc/cpuinfo

#cat   /sys/module/kvm_intel/parameters/ept

#cat   /sys/module/kvm_intel/parameters/vpid

#modprobe   kvm_intel   ept=0,vpid=0

大页（hugepages）

      大页(Huge Page) 的硬件要求：x86_­64CPU支持2MB大页；内核2.6以上支持大页

      大页的功能：减少内存页数量，从而需要更少的页表，节约页表所占用的内存数量，减少地址转换，提高内存访问性能。地址转换信息一般保存在CPU缓存中，减少地址转换信息，从而减少CPU缓存压力。

1）先查看不使用大页时的状态   

#getconf   PAGESIZE                           //内存的单位存储

#cat   /proc/meminfo  |  grep   Huge

2）使用大页

第一步 需要给大页一个存储位置，所以要挂载个大页格式的设备  

#mount   -t   hugetlbfs    hugetlbfs   /dev/hugepages

#hugepages=yes                               //开启大页

第二步 修改内核参数   #sysctl   vm.nr_hugepages=1024

注：1024的单位是个，所以内存为2M*1024=2048M

3）观察大页变化：

      多开启几个虚拟机，观察CPU、内存、硬盘与进程的变化。注意，用了大页之后就无法使用swap空间的交换了，也不能以ballooning方式增长。

      ballooning增长方式，如果物理机内存是6G，创建虚拟机1、2各是8G内存，虚拟机开机只用了2G内存，但是虚拟机都以为自己是8G内存，所以当虚拟机1需要运行应用时会向物理机请求内存（虚拟机不知道是请求，只知道自己有8G内存），假设是还要2G，物理机得知请求后会把空闲的2G分配给虚拟机1，虚拟机1运行完应用后不会主动将内存还给物理机（因为虚拟机只知道那是自己的内存），此时如果虚拟机2也需要2G内存运行程序，那么物理机会把虚拟机1的多余2G内存像挤气球一样挤出来分配给虚拟机2，如果内存还是不够用，那么物理机会把闲置的程序交换到swap分区，腾出内存空间。正常情况下，物理机会不断地挤气球，把闲置的内存空间尽量放在自己这里。

4）虚拟机想要使用大页的话，直接输入命令 #hugepages=yes 。或者在虚拟机的xml文件中添加内容：

<memoryBacking>

<hugepages/>

</memoryBacking>

注意，配置虚拟机建议就修改配置文件，三方工具功能不全。

内存超配

      内存80%-90%的时候就应该警惕，此时很快就会使用swap空间了，需要查一查是什么原因，且内存是否有使用增长趋势，为什么增长，增长就要解决。内存50%时，但是此时却用了1G的swap空间，这更要警惕了，除了NUMA会导致这种情况以外，还有别的原因。

      某服务器32GB物理内存，其上运行64个内存为1GB的客户机。宿主机需要4GB内存满足系统进程/驱动/磁盘缓存及其它应用程序所需内存（不包括客户机进程所需内存）。客户机交换分区大小为：1G*64+4G-­32G=36G；因此宿主机交换分区大小为：36G+8G=44G。

      内存的超配比1.2-1.5，也就是实际内存是1G的话，虚拟机内存加一起不能超过1.5G。生产环境中，实际内存与swap空间的比例=1:（1-2），但是根据行业说法，内存>8G时，swap就都给8G，不够用了再增加即可。增加swap空间的方法有dd文件,swapon 设备或分区，或者使用LVM

• 实际上swap空间就是自动实现了内存的超配，当内存不够用时，主机会使用swap进行交换，把待机的应用放到swap空间，正在使用的程序在内存中，但是swap空间会使得主机运行很慢。程序无响应就是因为内存不够了，swap交换很慢。
• balloon也能实现内存超配，但是需要安装驱动。通过virio_balloon驱动来实现宿主机Hypervisor和客户机之间的协作。
• 页面共享实现内存超配(page sharing) 通过KSM(Kernel Samepage Merging)合并多个客户机进程使用的相同内存页。