Labs简介所谓计算虚拟化，狭义上可以理解为对单个物理服务器的虚拟化，主要包括CPU、内存、I/O的虚拟化服务器上的设备。目的是实现多个虚拟机可以在一台服务器上独立运行，相互隔离。从广义上讲，还可以扩展到云资源池，将各种资源池组网场景下的CPU、内存、I/O设备等资源进行集成、抽象和虚拟化。一、服务器虚拟化平台概念回顾在上一篇《虚拟化基础》中，我们介绍了虚拟化基础的一些基本概念。这里简单回顾一下服务器平台虚拟化后的分层结构。如下：一个完整的服务器虚拟化平台从下到上包括以下几个部分：底层物理资源：包括网卡、CPU、内存、存储设备等硬件资源。通常，包含物理资源的物理机器称为主机）。虚拟机监视器（VirtualMachineMonitor，VMM）：VMM是位于虚拟机和底层硬件设备之间的虚拟层。需要资源，并且让各个虚拟机在同一个系统中独立运行，互不干扰。抽象虚拟机硬件：虚拟化层呈现的虚拟化硬件设备。虚拟机能发现哪些硬件设施完全由VMM决定。虚拟设备可以是模拟的真实设备，也可以是现实中不存在的虚拟设备，比如VMware的vmxnet网卡。虚拟机：相对于底层的物理机，也称为客户端（Guest）。其上运行的操作系统称为来宾操作系统（GuestOS）。每个虚拟机操作系统都有自己的虚拟硬件，运行在独立的虚拟环境中。通过VMM的隔离机制，每个虚拟机都认为自己是作为一个独立的系统运行的。同时，在之前的文章《虚拟化基础》中，我们提到了Hypervisor就是VMM。其实这种说法并不准确，至少在VMware的虚拟化解决方案中是这样。在VMware的ESX产品架构中，VMM和Hypervisor还是有一定区别的，如下图所示。Hypervisor是介于虚拟机和底层物理硬件之间的虚拟层，包括bootloader、x86平台硬件的抽象层以及内存和CPU调度器，负责对运行在其上的多个虚拟机进行资源调度。VMM是与上层虚拟机一一对应的进程，负责虚拟化指令集、内存、中断和基本I/O设备。运行虚拟机时，Hypervisor中的vmkernel会加载VMM，虚拟机直接运行在VMM上，通过VMM的接口与Hypervisor进行通信。在KVM和Xen架构中，虚拟层称为Hypervisor，即VMM=Hypervisor。判断一个VMM能否有效保证服务器系统实现虚拟化功能，必须具备以下三个基本特征：除了时序和资源可用性的不一致，它的行为应该与在相同条件下运行的物理服务器的行为一致。资源控制属性：VMM必须能够完全控制虚拟化资源。效率特性：除特权指令外，大部分机器指令都可以由硬件直接执行，无需VMM干预控制。以上三个基本特征也是服务器虚拟化实施方案的指导思想。2、x86平台虚拟化面临的问题和挑战基于x86的操作系统从一开始就被设计为直接运行在裸机硬件环境上，自然而然地拥有整机硬件的控制权限。为了保证操作系统能够安全地操作底层硬件，x86平台采用了特权模式和用户模式的概念，将内核程序与用户应用程序隔离开来。在该模型下，CPU提供了4个特权级，分别为Ring0、1、2、3。如下图所示：Ring0是最高特权级，对内存和硬件有直接的访问控制。一环、二环、三环的权限依次降低，无法执行Nehe系统级别设置的命令。相应地，运行在Ring0上的指令称为“特权指令”；那些在其他级别上运行的被称为“非特权指令”。Linux、Windows等常见操作系统运行在Ring0，而用户级应用程序运行在Ring3。如果一个低特权级的程序执行特权指令，就会造成“陷阱”内核态并抛出异常。当这种分层隔离机制应用于虚拟化平台时，为了满足VMM“资源可控”的特性，VMM必须在Ring0级别控制所有硬件资源并执行最高权限的系统调用。虚拟机操作系统GuestOS会降级运行在Ring1级别，因此GuestOS在执行特权指令时会造成“陷入困境”。如果VMM能够正常捕获异常，模拟并执行GuestOS下发的指令，目的就达到了。这是IBM的Power系列使用的特权剥夺和陷入仿真的机制，支持此功能的指令集通常被认为是“可虚拟化的”。但是……但是……但是……x86平台的指令集没有虚拟化。你为什么这么说？首先我们来看一下x86平台指令集的分类。x86平台的指令集大致分为以下四类：访问或修改机器状态的指令。访问或修改敏感寄存器或内存位置的指令，例如时钟寄存器和中断寄存器。用于访问存储保护系统或内存和地址分配系统（段页面等）的指令。所有I/O指令。其中1~4都是x86平台上的敏感指令。第一类和第四类指令是敏感指令中的特权指令，由操作系统内核执行。GuestOS在执行这两类指令时，不在Ring0级别，所以会trap并抛出异常，被VMM捕获，然后模拟GustOS执行，并返回执行结果到来宾操作系统。到目前为止，一切正常。但是，第二类和第三类指令是非特权指令，可以被应用程序调用，即可以在Ring3级别执行，调用GuestOS内核进程来完成。当应用程序调用这些指令时，由于需要修改内存和内部寄存器，这些状态修改需要GuestOS完成，此时GuseOS运行在Ring1级别，虽然traps也会会发生，但是不会抛出异常，所以VMM无法捕捉到，也就无法模拟。因此，当GuestOS执行这些指令时，虚拟机的状态就会出现异常，甚至服务器的状态也会受到影响。在x86平台下，一共有19条这样的指令，我称之为x86平台敏感指令中的边界指令。正是因为x86平台的指令集存在上述缺陷，所以为了在x86平台上应用计算虚拟化技术，各大虚拟化厂商纷纷推出了多种虚拟化技术，其目的就是着重于“如何捕获和模拟这19条边界指令”。设计的建议。长期以来，这个问题都是通过软件来解决的，包括不修改内核的全虚拟化和不修改内核的半虚拟化。半虚拟化虽然需要对GuestOS内核进行一定程度的修改，不符合“等价”要求，但在性能上明显优于全虚拟化。直到2005年Intel和AMD分别推出了VT-d和AMD-V，才能够在芯片层面支持全虚拟化，虚拟化技术才算完全完善，也就是现在所说的硬件辅助虚拟化技术。3.x86平台计算虚拟化解决方案3.1全虚拟化全虚拟化（FullVirtualization）和准虚拟化（Para-Virtualization）的划分是相对于是否修改GuestOS而言的。如下图所示，全虚拟化通过一层可以完全模拟物理硬件环境的虚拟软件，将GuestOS与底层物理硬件完全解耦。因此，GuestOS不需要任何修改，虚拟化环境对它来说是完全透明的。也就是说，在全虚拟化方案中，虚拟机并没有感知到自己处于虚拟化环境中，而认为自己一直运行在物理硬件上。如下图所示：在实现上，特权指令的二进制翻译机制通常与通用指令的直接执行相结合。具体来说，对于GuestOS下发的特权指令和边界指令，VMM会进行实时翻译并缓存结果（目的是提高虚拟化性能），而对于通用级指令，则不需要VMM干预，可以直接在硬件实现上执行。exception-capture-simulation的过程如下图所示：由于虚拟化环境对GuestOS是完全透明的，因此全虚拟化模式是虚拟机迁移和可移植性的最佳方案，虚拟机可以无缝迁移从虚拟环境迁移到物理环境。但是，软件模拟实现的全虚拟化无疑会增加VMM的上下文切换，因为这种方案实现的虚拟机性能不如半虚拟化方案。VMware的ESX系列产品和Workstations系列产品是全虚拟化技术的典型产品。3.2半虚拟化如上所述，x86平台上总有一些边界指令可以在Ring3级别执行。全虚拟化模式虽然通过实时翻译这些特殊指令解决了这个问题，但实现开销较大，性能不如在实际物理机上运行。为了提高性能，准虚拟化技术应运而生，“Para-Virtualization”可以理解为通过某种辅助方式实现虚拟化。半虚拟化解决方案如下图所示。半虚拟化为客户操作系统和虚拟化层之间的特殊指令添加了一个转换模块。通过修改GuestOS内核，将特权指令和边界指令的执行替换为对虚拟化层的hypercall调用。同时，虚拟层还提供了hypercall接口，用于内存管理、中断处理、时间同步等。hypercall调用流程如下图所示：这样可以显着提升虚拟机的性能。但是，对于一些不能修改内核的操作系统，比如Windows，就不能让它运行在半虚拟化环境中。而且，由于需要修改GuestOS内核，无法保证虚拟机物理环境和虚拟环境之间的透明切换。华为6.3版本之前的虚拟化解决方案开源项目Xen和FusionCompute修改了Linux内核和提供I/O虚拟化操作的Domain0专用虚拟机，使虚拟机运行在虚拟化上的性能环境可以接近于运行环境，是半虚拟化技术解决方案的典型产物，因为它在物理环境中的性能。但是随着业务规模的增大，特殊的虚拟机Domain0成为了该方案扩展性和性能的瓶颈。3.3硬件辅助虚拟化所谓“解铃必系铃”。对于敏感指令引发的一系列虚拟化问题，处理器硬件厂商最终给出了自己的解决方案。2005年，Intel和AMD跟随IBM的大型机虚拟化技术，分别推出了VT-x和AMD-V技术。如下图所示：第一代的VT-x和AMD-V都试图通过定义新的运行模式将GuestOS恢复到Ring0，让VMM运行在Ring0以下的级别（可以理解为Ring-1）。例如：在Intel的VT-x方案中，运行在非root模式下的GuestOS可以像非虚拟化平台一样运行在Ring0级别，不管是Ring0下发的特权指令还是下发的敏感命令通过环3。指令被困在根模式虚拟化层中。VT-x解决方案如下图所示：VT-x和AMD-V推出后，完美解决了x86平台虚拟化的缺陷，提升了性能，于是各虚拟化厂商迅速开发出相应的产品版本。用于支持该技术。例如：KVM-x86、Xen3.0、VMwareESX3.0之后的虚拟化产品。随后，Intel和AMD在第二代硬件辅助虚拟化技术中都推出了硬件辅助虚拟化技术VT-d和I/O的IOMMU。总结：x86平台下的三种虚拟化技术都是围绕x86在虚拟化方面的一些缺陷而产生的。下图比较了三种虚拟化技术。从图中可以看出，全虚拟化和半虚拟化GuestOS的权限级别被压缩在Ring1，而硬件虚拟化则将GuestOS恢复到Ring0级别。半虚拟化是修改GuestOS的内核，所有敏感指令和特权指令都以Hypercall的形式调用，而全虚拟化和硬件虚拟化则不需要修改GuestOS。在全虚拟化中，特权指令和敏感指令采用动态二进制翻译，而硬件虚拟化则在芯片中增加了根模式支持，修改了敏感指令的语义，因此所有特权指令和敏感指令都可以自动陷入根模式虚拟机。【本文为专栏作家《移动实验室》原创稿件，转载请联系原作者】点此阅读更多本作者好文
