分类：
2010-12-19 21:33:04
早在上世纪70 年代，IBM System 360、370、CP-40、CP-67[1-4]等系统就已经实现了硬件抽象层的虚拟机技术，它最初是为了弥补系统架构上的不足而发展起来的，而随着技术的发展和对虚拟机需求的增加，硬件抽象层虚拟机在强隔离功能和安全控制方面得到了长足发展和广泛应用。
如前所述，运行在硬件抽象层虚拟机之上的软件即为客户操作系统，硬件抽象层的虚拟机技术利用客户系统环境和虚拟机宿主平台的相似性来减少执行客户系统指令的延迟。目前，大多数的商业服务器虚拟化产品，都是通过使用这种技术来实现高效、实用的虚拟化系统。这种技术利用虚拟机监视器（Virtual Machine Monitor，VMM）作为隔离代码运行环境的中间层。
这类虚拟机通过VMM 提供了一个物理机器的抽象，它允许操作系统假设自身可以直接在硬件上运行，VMM为其上运行的客户操作系统提供硬件映射。从操作系统的角度看，运行在虚拟机上与运行在其对应的物理计算机系统上一样。
Type I VMM与Type II VMM体系结构
按照Goldberg的定义[5]，虚拟机监视器是能够为计算机系统创建高效、隔离的副本的软件。这些副本即为虚拟机（Virtual Machine，VM），在虚拟机内虚拟处理器的指令集的一个子集能够直接在物理处理器上执行。根据VMM 在整个物理系统中的实现位置和实现方法的不同，Goldberg定义了两种虚拟机监视器模型，即Type I VMM和Type II VMM，具体结构如图1所示。Type I VMM 在操作系统之前预先安装，然后在此虚拟机监视器之上安装客户操作系统，它可以在硬件支持下拥有最佳性能，如IBM VM/370[1-3]，VMware ESX Server[6]，Xen[7-9]，Denali[10-12]等均属于这样的虚拟机。Type I VMM通常都是以一个轻量级操作系统的形式实现。Type II VMM 则是安装在已有的主机操作系统（宿主操作系统）之上，此类虚拟机监视器通过宿主主操作系统来管理和访问各类资源（如文件和各类I/O设备等)，如VMware Workstation[13]、Parallel Workstation[14]等。
从实现的角度，VMM实现从虚拟资源到物理资源的映射，并利用本地物理计算机系统进行实际计算。当客户操作系统通过特权指令访问关键系统资源时，VMM将接管其请求，并进行相应的模拟处理。为了使这种机制能够有效地工作，每条特权指令的执行都需要产生自陷（Trap）以便VMM能够捕获该指令，从而使得VMM能够进行相应的指令模拟执行。VMM通过模拟特权指令的执行，并返回处理结果给指定的客户虚拟系统的方式，实现了不同虚拟机的运行上下文保护与切换，从而能够虚拟出多个硬件系统，保证了各个客户虚拟系统的有效隔离。
然而，Intel x86体系结构的处理器并不是完全支持虚拟化的[15]，因为某些x86特权指令在低特权级上下文执行执行时，不能产生自陷，导致VMM无法直接捕获特权指令的执行。
目前，针对这一问题的解决方案主要有三种：基于动态指令转换（Dynamic Instruction Translation）的完全虚拟化（Full-virtualization）技术，半虚拟化（Para-virtualization）技术和硬件辅助（Hardware Assisted）技术。
许多商业的虚拟化产品都采用了基于动态指令转换的完全虚拟化技术，例如EMC公司的VMwareESX Server、VMware Workstation和Microsoft的Virtual Server系列产品。基于动态指令转换的完全虚拟化技术通过在运行时动态执行指令扫描以发现特权指令，然后依据VMM状态执行指令转换，使得特权指令的执行跳转到等价模拟代码段处，从而实现与自陷相同的目标。
由于完全虚拟化不需要修改客户操作系统，因此具有很好的兼容性，而完全虚拟化技术的性能也主要依赖于动态指令转换引擎的设计和实现。
与完全虚拟化技术技术不同，半虚拟化技术通过修改操作系统代码使特权指令产生自陷。半虚拟化技术最初由Denali[10]和Xen 项目[7] 在x86 体系架构上实现。Denali最先提出半虚拟化技术，Xen是由剑桥大学计算机实验室发起的开源虚拟机项目。它的开发得到了Intel、HP、IBM等公司的支持。Xen是在x86平台上支持同时运行多个虚拟系统的高性能VMM，它支持x86_32、x86_64、IA64等多种平台。
Xen采用半虚拟化技术，通过对客户操作系统的内核进行适当的修改，使其能够在VMM的管理下尽可能地直接访问本地硬件平台。Xen利用半虚拟化技术降低了由于虚拟化而引入的系统性能损失。如图2所示，Xen的 半虚拟化技术的主要实现思路是：对于内存分段管理的虚拟化，要求客户操作系统对硬件分段描述符的更新由Xen进行验证，这也就要求客户操作系统不能有高于Xen的特权级别和不允许访问Xen的保留地址空间；对于内存分页管理的虚拟化，要求客户操作系统可以直接读取硬件页表，但对页表的更新需要Xen进行验证和处理，Xen支持客户虚拟系统可以分布在不连续的物理内存上；对于客户虚拟系统，其只能运行在低于Xen的特权级别上；客户虚拟系统需要注册一个异常（Exception）处理函数的描述符表，直接支持Xen的虚拟化；客户虚拟系统的硬件中断机制被Xen中的Event处理机制代替；每个客户虚拟系统都有自己的时钟接口，并且可以了解真实的时间和虚拟的时间；客户虚拟系统通过异步I/O rings的内存区域和外部设备（网络、硬盘）来传递数据，采用事件处理机制代替硬件中断通知机制。
体系结构
目前，Xen的最新的3.x版本已经支持Intel VT和AMD Pacifica技术，基于Intel VT技术避免了对客户操作系统内核的修改[8, 16]，这一技术将使得能够在Xen之上运行各种非开源操作系统（如Windows等）。Xen作为高性能的虚拟机软件[8]，越来越受到业界的关注，并在企业计算和计算机安全领域都得到了广泛的应用[9, 17-28]。
第三种方案是通过修改x86 CPU指令的语义使其直接支持虚拟化，也就是Intel的VT（Virtualization Technology）技术[29-31]和AMD的Pacifica[32]技术的目标。Intel 公司推出了VT-i(支持Ltanium 架构)和VT-x（支持X86 架构）引入新的处理器操作，称为VMX(Virtual Machine Extensions)来支持虚拟化。AMD 推出了新的处理器模式和新的内存管理模式支持虚拟化技术。VT的核心思想是给x86 CPU的各种特权指令的执行，都增加可以进行trap的可能。
AMD在虚拟化技术方面的Pacifica技术规范，是AMD计划用于其64位产品中的虚拟化技术。该技术将用于基于x86架构的服务器、台式机和笔记本电脑等系列产品。
从技术角度看，不论是 VT技术外部架构规范，还是Pacifica技术规范，它们强调的核心功能都是RISC处理器早就实现了分区（Partition）功能，即基于该技术平台实现在独立分区中高效运行多个操作系统和应用程序，使一个计算机系统像多个虚拟系统一样运行。
除了基于VMM的硬件抽象层的虚拟机技术，还有一种基于软件模拟指令集方式实现的所谓ISA（Instruction Set Architecture）层虚拟机系统。一个典型的计算机系统由处理器、内存、总线、硬盘控制器、时钟、各种I/O设备组成。ISA层的虚拟化软件的实现方式是截获客户操作系统发出的指令，并把它们“翻译”成宿主平台上的可用指令进行执行（包括处理器内部指令和I/O指令）。由于这种指令的模拟方式，ISA层的虚拟化技术可以完全模拟一台真实机器，这种实现方式的好处在于，分离了操作系统和硬件平台的紧绑定关系。
这方面具有代表性的系统有很多。Bochs[33]是用C++语言编写的开源的x86平台的PC模拟器，可以方便地在多种平台上模拟IA32 PC系统。它能够模拟多种版本的x86系统，如386、486、Pentium、Pentium Pro、SSE、SSE2等指令。Bochs解释客户系统从开机到关机的全部指令，模拟了Intel x86 CPU、BIOS以及PC设备。因此，在客户操作系统看来，就好像是运行在一台真实的机器上一样。虽然Bochs系统的性能问题，使其很难有广泛的应用，但它也在某些方面有着重要的应用价值，如在非x86平台上运行Windows系统，进行新开发的操作系统的debug工作，进行老式x86系统的兼容性测试等。
QEMU [34]是一个采用动态指令转换技术的快速的模拟器，它支持两种工作模式：用户空间模拟和全系统模拟。在用户空间模式下，QEMU可以在物理 CPU上执行为其他CPU编译的程序。在全系统模拟的模式下，它支持模拟x86、ARM、PowerPC、Sparc等结构。它可以快速地把客户操作系统的指令动态地翻译成本地指令进行执行。QEMU进行动态指令转换的基本思想是把每条指令分解成少量的简单指令。每条简单指令由一段C代码实现，通过动态代码生成器把这些简单指令的目标文件连接起来，构建指定的功能。
与基于VMM的硬件抽象层虚拟机不同，ISA层的虚拟机技术模拟运行所有客户操作系统执行的处理器指令。因此，这种虚拟机技术最大的不足就是性能问题，它的性能远远低于硬件抽象层的虚拟机，所以主要应用于动态指令转换等研究领域。
硬件抽象层的虚拟化技术有着高度的客户虚拟系统的隔离性（包括客户操作系统之间，客户操作系统和宿主操作系统之间）。这种隔离性使得在同一个物理平台上，可以同时运行不同类型的操作系统，而且它们的重启等操作不会互相影响。在用户看来，隔离性使得物理平台被划分成不同虚拟机器。由于用户面对的是虚拟机器，用户需要更多的系统安装和配置工作。
参考文献
[1] Schaefer M, Gold B, Linde R, et al. Program Confinement in KVM/370[C]. Proceedings of the 1977 ACM Annual Conference, 1977. 1977: 404–410.
[2] Gold B D, Linde R R, Schaefer M, et al. VM/370 Security Retrofit Rrogram[C]. Proceedings of the 1977 ACM Annual Conference, 1977. 1977: 411-418.
[3] Seawright L H, Mackinnon R A. VM/370 - a Study of Multiplicity and Usefulness[J]. IBM Systems Journal. 1979.
[4] Creasy R J. the Origin of theVM/370 Time-sharing System[J]. IBM Journal of Research and Development. 1981.
[5] Goldberg R P. Architecture of Virtual Machines[C]. Proceedings of the Workshop on Virtual Computer Systems, 1973. 1973: 74-112.
[6] Waldspurger C A. Memory Resource Management in VMware ESX Server[C]. Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI '02), 2002. 2002: 181-194.
[7] Barham P, Dragovic B, Fraser K, et al. Xen and the Art of Virtualization[C]. Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP'03), 2003. 2003: 164-177.
[8] Ian P, Keir F, Steve H, et al. Xen 3.0 and the Art of Virtualization[C]. Proceedings of the Ottawa Linux Symposium, 2005. 2005: .
[9] Clark B, Deshane T, Dow E, et al. Xen and the Art of Repeated Research[C]. Proceedings of the USENIX Annual Technical Conference, 2004. 2004: 47-56.
[10] Whitaker A, Shaw M, Gribble S D. Denali: A Scalable Isolation Kernel[C]. Proceedings of the 10th ACM SIGOPS European Workshop, 2002. 2002: 10-15.
[11] Whitaker A, Shaw M, Gribble S D. Denali: Lightweight Virtual Machines for Distributed and Networked Applications[R]. University of Washington Technical Report 02-02-012002.
[12] Whitaker A, Shaw M, Gribble S D. Scale and Performance in the Denali Isolation Kernel[J]. ACM SIGOPS Operating Systems Review, OSDI '02: Proceedings of the 5th Symposium on Operating Systems Design and Implementation. 2002, 36(SPECIAL ISSUE: Virtual machines).
[13] Sugerman J, Venkitachalam G, Lim B H. Virtualizing I/O Devices on VMware Workstation's Hosted Virtual Machine Monitor[C]. Proceedings of the 2001 USENIX Annual Technical Conference, 2001. 2001: 1-14.
[14] Swsoft. Parallel Workstation. [Z].
[15] Robin J S, Irvine C E. Analysis of the Intel Pentium's Ability to Support a Secure Virtual Machine Monitor[C]. Proceedings of the 9th USENIX Security Symposium, 2000. 2000: 129–144.
[16] Yaozu D, Shaofan L, Asit M, et al. Extending Xen with Intel Virtualization Technology[J]. Intel Technology Journal. 2006, 10(3): 193-203.
[17] Gupta D, Gardner R, Cherkasova L. XenMon: QoS Monitoring and Performance Profiling Tool[R]. Tech Report: HPL-2005-1872005.
[18] Haifeng X, Sihan Q, Huanguo Z. XEN Virtual Machine Technology and Its Security Analysis[J]. Wuhan University Journal of Natural Sciences. 2007, 12.
[19] Anwar Z, Campbell R H. Secure Reincarnation of Compromised Servers using Xen Based Time-Forking Virtual Machines[C]. 5th IEEE International Conference on Pervasive Computing and Communications Workshops (PerComW'07), 2007. 2007: 477-482.
[20] Fraser K, Hand S, Neugebauer R, et al. Safe Hardware Access with the Xen Virtual Machine Monitor[C]. 2004. 2004: 1-10.
[21] Quynh N A, Takefuji Y. A Novel Approach for a File-system Integrity Monitor Tool of Xen Virtual Machine[C]. Proceedings of the 2nd ACM Symposium on Information, Computer and Communications Security, 2007. 2007: 194-202.
[22] Gardner L C. Measuring CPU Overhead for I/O Processing in the Xen Virtual Machine Monitor[C]. USENIX 2005 Annual Technical Conference, 2005. 2005: 387-390.
[23] Chen H, Chen R, Zhang F, et al. Live Updating Operating Systems Using Virtualization[C]. Proceedings of the 2st ACM/USENIX International Conference on Virtual Execution Environments, 2006. 2006: 35-44.
[24] Kourai K, Chiba S. HyperSpector: Virtual Distributed Monitoring Environments for Secure Intrusion Detection[C]. Proceedings of the 1st ACM/USENIX International Conference on Virtual Execution Environments (VEE'05), 2005. 2005: 197-207.
[25] Youseff L, Wolski R, Gorda B, et al. Evaluating the Performance Impact of Xen on MPI and Process Execution for HPC Systems[C]. the First International Workshop on Virtualization Technology in Distributed Computing (VTDC), held in conjunction with Supercomputing (SC06), 2006. 2006: 1-8.
[26] Gupta D, Cherkasova L, Gardner R, et al. Enforcing Performance Isolation Across Virtual Machines in Xen[C]. Proceeding of the ACM/IFIP/USENIX 7th International Middleware Conference (Middleware'06), 2006. 2006: 342-362.
[27] Menon A, Santos J R, Turner Y, et al. Diagnosing Performance Overheads In the Xen Virtual Machine Environment[C]. Proceedings of the 1st ACM/USENIX International Conference on Virtual Execution Environments, 2005. 2005: 13-23.
[28] Sailer R, Jaeger T, Valdez E, et al. Building a MAC-Based Security Architecture for the Xen Open-Source Hypervisor[C]. Proceedings of the 21st Annual Computer Security Applications Conference (ACSAC'05), 2005. 2005: 276-285.
[29] Uhlig R, Neiger G, Rodgers D, et al. Intel Virtualization Technology[J]. IEEE Computer. 2005, 38(5): 48-56.
[30] Abramson D, Jackson J, Muthrasanallur S, et al. Intel Virtualization Technology for Directed I/O[J]. Intel Technology Journal. 2006, 10(3): 179–192.
[31] Neiger G, Santoni A, Leung F, et al. Intel Virtualization Technology: Hardware Support for Efficient Processor Virtualization[J]. Intel Technology Journal. 2006, 10(3): 167–177.
[32] Amd. AMD64 Vrtualization Codenamed "pacifica" Technology: Secure Virtual Machine Architecture Reference Manual[Z]. 2005.
[33] Lawton K. the Bochs IA-32 Emulator Project, [Z].
[34] Bellard F. QEMU, a Fast and Portable Dynamic Translator[C]. Proceedings of the USENIX Annual Technical Conference (USENIX'05), 2005. 2005: 41-46.
一个典型的应用程序运行环境包括：操作系统、用户函数库、文件系统、环境设置等。如果一个运行环境包含了所有这些关键组件，应用程序自身是无法区分是运行在物理系统内，还是运行在虚拟系统中。操作系统层虚拟化技术的主要思想就在于此，即在宿主操作系统上动态复制软件运行环境，以此来创建多个虚拟系统。
Jail[1, 2]是FreeBSD上的操作系统层虚拟机技术。它把操作系统划分成多个独立的环境，称之为Jail。每个Jail都可以独立管理典型的操作系统资源，如进程、文件系统、网络资源等。而用户对资源的访问范围则被限制在该用户所在Jail的内部。Jail是通过Jail系统调用创建的，Jail 内的第一个进程的所有子进程都属于该Jail，任何一个进程不能同时属于多个Jail。Jail虚拟化技术在隔离应用程序方面有一定的应用价值。
Solaris操作系统提供的区域（Zone）技术 [3, 4]也采用了类似的机制。区域是指在 Solaris 操作系统的单个实例中创建的一个虚拟的操作系统环境，是一种用于虚拟化操作系统服务的分区技术，目的是提供安全的隔离环境以便承载和运行各种应用程序。区域有两种类型：全局区域（global zone）和非全局区域 （non-global zone）。通过系统硬件引导的 Solaris安装过程所安装的即是全局区域，一个系统中只能运行一个全局区域。全局区域管理员可使用 zonecfg和zoneadm来创建非全局区域。全局区域控制所有非全局区域的安装、维护、操作和损毁。Solaris 区域功能可为在非全局区域中运行的进程提供虚拟服务和名称空间隔离。它可以将在某个非全局区域中运行的进程与在其他区域中运行的进程隔离开，这种隔离可防止在某个非全局区域中运行的进程监视或影响在其他区域中运行的进程。对于在非全局区域中运行的进程，即使具有超级用户权限也不能查看或影响其他区域中的活动。区域还提供一个抽象层，用以分隔应用程序与部署应用程序的计算机的物理属性，例如物理设备路径和网络接口名称等。
Virtual Private Server（VPS）[5]技术把服务器的操作系统环境分割成多个彼此隔离的虚拟运行容器，称之为VPS。管理员可以为每个VPS分配指定数量的内存、磁盘、网络带宽等资源，还能够在物理服务器与虚拟环境或物理服务器之间进行客户虚拟系统的迁移。VPS技术在网站的服务器整合，提高资源利用率等方面有很好的应用。
体系结构
UML（User Mode Linux）[6-8]是让一个Linux作为一个独立进程运行在另一个Linux（宿主Linux）之上的开源项目，它是一种在同一时刻运行多 Linux 的虚拟化方式。UML不需要额外的虚拟化软件，它只需要在Linux内核源码上打上相关的补丁。UML的补丁把Linux标准内核转化成一个可以作为独立进程执行的操作系统。当运行UML内核时，需要为其分配一个完整的文件系统。新的系统内核作为一个用户态的应用程序运行。UML体系结构如图2.4所示，UML内核接收来自应用程序的系统调用请求，然后发送到宿主Linux内核进行处理。由于UML的内核和用户态进程在同一地址空间内，因此，需要把内核的代码和数据段放在UML进程通常不会使用的地方。为了让UML之间共享内核数据，UML内核被映射到一个文件，然后将这个文件映射到UML进程中。目前，UML主要被用于系统软件的调试和测试。
参考文献
[1] Kamp P H, Watson R N. Jails: Confining the omnipotent root[C]. 2nd International System Administration and Network Engineering Conference (SANE'00), 2000. 2000: 1-15.
[2] Evan S. Securing freeBSD using jail[J]. Sys Admin. 2001, 10(5): 31-37.
[3] Price D, Tucker A. Solaris Zones: Operating System Support for Consolidating Commercial Workloads[C]. USENIX 18th Large Installation System Administration Conference (LISA'04), 2004. 2004: 241-254.
[4] Tucker A, Comay D. Solaris Zones: Operating System Support for Server Consolidation[C]. USENIX 3rd Virtual Machine Research and Technology Symposium (VM'04), 2004. 2004: 1-2.
[5] Linux-VServer, [Z].
[6] Dike J. A User-mode Port of the Linux Kernel[C]. Proceedings of the 4th Annual Linux Showcase & Conference, Atlanta, Georgia, USA, 2000. Atlanta, Georgia, USA: 2000: 7-16.
[7] Hoxer H J, Buchacker K, Sieh V. Implementing a User-Mode Linux with Minimal Changes from Original Kernel[C]. Proceedings of the 2002 International Linux System Technology Conference, 2002. 2002: 72-82.
[8] Jeff D. User Mode Linux[M]. Prentice Hall, 2006.
API层虚拟机的典型代表是开源项目Wine，它构造了一个Windows用户态应用程序和其它操作系统之间的适配层（Adapter Layer），当这些应用程序需要在其他操作系统下调用一个Win32 API函数时，Wine将把该调用转换成相应操作系统下对该函数的模拟实现。
Wine系统在整个运行环境中起到的作用可以从三个角度理解。
l 从Windows应用程序的角度看，Wine为其提供了Windows软件运行环境的模拟，不过这并不是对处理器指令的模拟，而是对Win32 API函数的模拟。
l 从Linux及其内核的角度看，Wine形成Linux内核与Windows应用程序之间的一个中间层。它一方面为Windows应用程序提供了一套完整的动态链接库（Dynamic Link Library，DLL），一方面将应用程序和动态链接库中对Windows的系统调用转换成具有相似语义的Linux的系统调用。
l 从Windows的动态连接库和服务进程的角度来看，Wine是Windows关键组件以模拟方式在Linux上实现的移植。
Wine体系结构
Wine未包含任何Linux内核模块，即Wine所有的组件均是在用户态实现的。Wine需要在Linux用户态下基于Linux系统调用来模拟实现Windows的系统调用。然而，系统调用类似于函数调用，要让两个这样的“函数调用”在调用上下文、输入参数、函数语义和返回结果等各方面都完全一致是非常困难的。为了在用户态弥补这一语义鸿沟，Wine引入了Wine Server这一服务进程。
如图1所示，Wine构造了Windows应用软件与Linux内核之间的适配层，主要包括了一个Wine服务进程（Wine Server）和一组Windows动态连接库。此外，Wine对用户界面API的模拟仍依赖于X Server。在运行Windows应用程序时，Wine需要与三个进程交互：
l Windows应用程序进程。该进程对Windows API函数调用均经由Wine所提供的各种动态连接库逐层向下转发，直至Linux内核系统调用。在Wine内部，这个进程需要通过套接字（socket）和管道（pipe）接口与Wine服务进程通信，以调用Wine服务进程提供的系统功能并接受服务进程的管理。Wine上运行的Windows应用程序进程是从Wine的作业载入程序wine迁移过来的，wine为该应用程序的运行建立起与Wine服务进程的连接之后载入目标程序，最后转入目标程序的入口函数（WinMain函数）开始运行。
l Wine服务进程。该进程提供Windows进程间通信与同步的手段、Windows进程与线程管理、注册表服务、各种Win32对象的管理等。Wine服务进程对进程、进程间通信等的管理与Linux内核所提供的相关服务并不冲突，因此只提供了Linux内核中不存在或者与Windows内核不兼容的部分。Wine服务进程实际是在为Windows应用程序提供远地过程调用（Remote Procedure Call，RPC）。可以说，Wine服务进程是整个Wine平台的核心，通过该服务进程，Wine在用户空间构造了一个虚拟的“Windows内核”。Wine服务进程的目的实际就是在用户态弥补Windows内核与其他操作系统内核的差异，尽管远程过程调用的方式带来了一定程度的性能下降，但也避免了修改Linux内核带来的潜在不稳定因素。
l X服务进程。该进程提供非Windows运行环境下的GUI服务，如图形显示输出以及键盘和鼠标输入等。
