摘要
虚拟化是云计算系统中的一种基础技术,可以说当前一个云计算服务必定是构建在虚拟化的基础上的。本文首先介绍了不同抽象层次的虚拟化技术,之后对应用广泛的系统级虚拟化和操作系统级虚拟化进行了更详细的分类和描述,最后介绍了各种典型虚拟化方案的具体实现。
1 引言
虚拟化是计算机系统中的一个重要概念,基本上每个计算机系统都提供一个给上层软件的界面,从处理器提供的基本指令集到很多中间件系统提供的巨大的应用程序界面集。虚拟化本质上是扩展或替换一个现存界面来模仿另一个系统的行为,其对计算机系统的重要性主要体现在以下几个方面。
相比高层软件(比如中间件和应用软件),硬件和底层系统软件变化得比较快,也就是说,我们面对的一种情况是旧有软件的维护跟不上下层平台更新的步伐。通过移植旧有软件的底层接口到新平台,可使得一大类的现有软件可以立刻在新平台上工作。
在服务器机器上,一个组织为它提供的每个服务都分配一台虚拟机,接着,将虚拟机以最佳方式分配到物理服务器上。与进程不同,虚拟机能很简单地迁移到其他物理机器上,这增加了管理服务器基础设施的灵活性。这个方法能潜在地减少服务器计算机的投资并减少能量消耗,后者是大型服务器中心的关键问题。
虚拟化技术和云计算的提供极为相关。云计算采用了这样一个模型,即作为一个服务,提供云上创建的存储、计算和高层对象。所提供的服务覆盖从诸如物理体系结构等的底层方面(基础设施即服务IaaS)到诸如软件平台(平台即服务PaaS),再到任意应用层次的服务(软件即服务SaaS)。云服务的提供被虚拟化技术直接驱动,允许为云的用户提供一个或多个虚拟机,供用户自己使用。
分布式应用的需求也激发虚拟化解决方案的开发者去以很少的开销创建和销毁虚拟机。在可能需要动态地请求资源的应用中,这是必要的。例如对于多人在线游戏或分布式多媒体应用,通过采用合适的资源分配策略满足虚拟机服务质量需求,能提升对这样的应用的支持度。
另一个好处是,在单台计算机上提供对几个不同操作系统环境的便利访问,虚拟化可用于在一种物理体系结构上提供多种操作系统类型。
虚拟化技术起始于IBM370体系结构,它的VM操作系统能为运行在同一计算机上的不同程序提供几个完整的虚拟机。最近,人们对虚拟化的兴趣大增,有许多研究项目和商业系统为商用PC、服务器和云基础设施提供虚拟化解决方案。
2 虚拟化技术的分类
现代计算机系统是一个庞大的整体,整个系统的复杂性是不言而喻的。因而,整个计算机系统被分成了多个自下而上的层次,每一个层次都向上一层次呈现一个抽象,并且每一层只需知道下层抽象的接口,而不需要了解其内部运作机制。这样以层的方式抽象资源的好处是每一层只需要考虑本层设计以及与相邻层间的相互交互,从而大大降低了系统设计的复杂性,提高了软件的移植性。
本质上,虚拟化就是由位于下层的软件模块,通过向上一层软件模块提供一个与它原先所期待的运行环境完全一致的接口的方法,抽象出一个虚拟的软件或硬件接口,使得上层软件可以直接运行在虚拟的环境上。虚拟化可以发生在现代计算机系统的各个层次上,不同层次的虚拟化会带来不同的虚拟化概念。
如前文所述,虚拟化技术起源于上世纪70年代的IBM370体系,经过四十余年的发展,当前存在诸多实现在不同层次的虚拟化技术,原理不尽相同,且每一种技术都相当复杂。在本文中,将通过不同的角度对目前存在的较流行的虚拟化技术进行分类,并对其原理进行初步介绍,旨在对纷繁复杂的虚拟化技术有个整体认识及厘清不同虚拟化技术之间的相互关系。
2.1 不同抽象层次的虚拟化技术
在介绍各种虚拟化概念之前,先介绍虚拟化中的两个重要名词。在虚拟化中,物理资源通常有一个定语称为宿主(Host),而虚拟出来的资源通常有一个定语称为客户(Guest)。
在计算机系统中,从底层至高层依次可分为:硬件层、操作系统层、函数库层、应用程序层,在对某层实施虚拟化时,该层和上一层之间的接口不发生变化,而只变化该层的实现方式。从使用虚拟资源的Guest的角度来看,虚拟化可发生在上述四层中的任一层。应当注意,在对Guest的某一层进行虚拟化时,并未对Host在哪一层实现它作出要求,这一点是时常引起混淆的地方。
2.1.1 硬件抽象层上的虚拟化
硬件抽象层上的虚拟化是指通过虚拟硬件抽象层来实现虚拟机,为客户机操作系统呈现和物理硬件相同或相近的硬件抽象层,又称为指令集级虚拟化,实现在此层的虚拟化粒度是最小的。
实现在此层的虚拟化技术可以对整个计算机系统进行虚拟,即可将一台物理计算机系统虚拟化为一台或多台虚拟计算机系统,故又可称作系统级虚拟化。每个虚拟计算机系统(简称为虚拟机)都拥有自己的虚拟硬件(如CPU、内存和设备等),来提供一个独立的虚拟机执行环境。每个虚拟机中的操作系统可以完全不同,并且它们的执行环境是完全独立的。由于客户机操作系统所能看到的是硬件抽象层,因此,客户机操作系统的行为和在物理平台上没有什么区别。
2.1.2 操作系统层上的虚拟化
操作系统层上的虚拟化是指操作系统的内核可以提供多个互相隔离的用户态实例。这些用户态实例(经常被称为容器)对于它的用户来说就像是一台真实的计算机,有自己独立的文件系统、网络、系统设置和库函数等。
由于这是操作系统内核主动提供的虚拟化,因此操作系统层上的虚拟化通常非常高效,它的虚拟化资源和性能开销非常小,也不需要有硬件的特殊支持。但它的灵活性相对较小,每个容器中的操作系统通常必须是同一种操作系统。另外,操作系统层上的虚拟化虽然为用户态实例间提供了比较强的隔离性,但其粒度是比较粗的。
2.1.3 库函数层上的虚拟化
操作系统通常会通过应用级的库函数提供给应用程序一组服务,例如文件操作服务、时间操作服务等。这些库函数可以隐藏操作系统内部的一些细节,使得应用程序编程更为简单。不同的操作系统库函数有着不同的服务接口,例如Linux的服务接口是不同于Windows的。库函数层上的虚拟化就是通过虚拟化操作系统的应用级库函数的服务接口,使得应用程序不需要修改,就可以在不同的操作系统中无缝运行,从而提高系统间的互操作性。
例如,Wine就是在Linux上模拟了Windows的库函数接口,使得一个Windows应用程序能够在Linux上正常运行。
2.1.4 编程语言层上的虚拟化
另一大类编程语言层上的虚拟机称为语言级虚拟机,例如JVM(Java Virtual Machine)和微软的CLR(Common Language Runtime)。这一类虚拟机运行的是进程级的作业,所不同的是这些程序所针对的不是一个硬件上存在的体系结构,而是一个虚拟体系结构。这些程序的代码首先被编译为针对其虚拟体系结构的中间代码,再由虚拟机的运行时支持系统翻译为硬件的机器语言进行执行。
2.2 系统级虚拟化
系统级虚拟化即硬件抽象层上的虚拟化、指令集级虚拟化,是最早被提出和研究的一种虚拟化技术,当前存在多种此种技术的具体实现方案,在介绍它们之前,有必要先了解实现系统级虚拟化可采取的途径。
在每台虚拟机中都有属于它的虚拟硬件,通过虚拟化层的模拟,虚拟机中的操作系统认为自己仍然是独占一个系统在运行,这个虚拟化层被称为虚拟机监控器(Virtual Machine Monitor,VMM)。VMM对物理资源的虚拟可以归结为三个主要任务:处理器虚拟化、内存虚拟化和I/O虚拟化。其中,处理器虚拟化是VMM中最核心的部分,因为访问内存或进行I/O本身就是通过一些指令来实现的。
2.2.1 可虚拟化架构和不可虚拟化架构
在系统级虚拟化中,虚拟计算机系统和物理计算机系统可以是两个完全不同ISA(Instruction Set Architecture,指令集架构)的系统,例如,可以在一个x86的物理计算机上运行一个安腾的虚拟计算机。但是,不同的ISA使得虚拟机的每一条指令都需要在物理机上模拟执行,从而造成性能上的极大下降。
显然,相同体系结构的系统虚拟化通常会有比较好的性能,并且VMM实现起来也会比较简单。这种情况下虚拟机的大部分指令可以在处理器上直接运行,只有那些与硬件资源关系密切的敏感指令才会由VMM进行处理。此时面前的一个问题是,要能将这些敏感指令很好地筛选出来。但事实上,某些处理器在设计之初并没有充分考虑虚拟化的需求,导致没有办法识别出所有的敏感指令,因而不具备一个完备的可虚拟化结构。
大多数的现代计算机体系结构都有两个或两个以上的特权级,用来分隔系统软件和应用软件。系统中有一些操作和管理关键系统资源的指令会被定为特权指令,这些指令只有在最高特权级上才能够正确执行。如果在非最高特权级上运行,特权指令会引发一个异常,处理器会陷入到最高特权级,交由系统软件来处理。
在x86架构中,所有的特权指令都是敏感指令,然而并不是所有的敏感指令都是特权指令。
为了VMM可以完全控制系统资源,它不允许虚拟机上操作系统直接执行敏感指令。如果一个系统上所有敏感指令都是特权指令,则能够用一个很简单的方法来实现一个虚拟环境:将VMM运行在系统的最高特权级上,而将客户机操作系统运行在非最高特权级上,当客户机操作系统因执行敏感指令而陷入到VMM时,VMM模拟执行引起异常的敏感指令,这种方法被称为“陷入再模拟”。
总而言之,判断一个架构是否可虚拟化,其核心就在于该结构对敏感指令的支持上。如果一个架构中所有敏感指令都是特权指令,则称其为可虚拟化架构,否则称为不可虚拟化架构。
2.2.2 按照实现方法分类
系统级虚拟化有许多不同的具体实现方案,按照实现方法的不同,可划分为如下几个类别。
(1)仿真(Emulation)
我们已经知道,通过陷入再模拟敏感指令的执行来实现虚拟机的方法是有前提条件的:所有的敏感指令必须都是特权指令。如果一个体系结构上存在敏感指令不属于特权指令,那么其就存在虚拟化漏洞,可以采用一些方法来填补或避免这些漏洞。最简单直接的方法是,所有指令都采用模拟来实现,就是取一条指令,就模拟出这条指令执行的效果。这种方法称作仿真。
仿真是最复杂的虚拟化实现技术,使用仿真方法,可以在一个x86处理器上运行为PowerPC设计的操作系统,这在其它的虚拟化方案中是无法实现的。甚至可以运行多个虚拟机,每个虚拟机仿真一个不同的处理器。此外,这种方法不需要对宿主操作系统的特殊支持,虚拟机可以完全作为应用层程序运行。
正如前面提到的,使用仿真方法的主要问题是速度会非常慢。由于每条指令都必须在底层硬件上进行仿真,因此速度减慢100倍的情况也并不稀奇。若要实现高度保真的仿真,包括周期精度、CPU的缓存行为等,实际速度差距甚至可能会达到1000倍之多。
使用这种方式的典型实现是Bochs。
(2)完全虚拟化(Full Virtualization)
在客户操作系统看来,完全虚拟化的虚拟平台和现实平台是一样的,客户机操作系统察觉不到是运行在一个虚拟平台上,这样的虚拟平台可以运行现有的操作系统,无须对操作系统进行任何修改,因此这种方式被称为完全虚拟化。
进一步说,客户机的行为是通过执行反映出来的,因此VMM需要能够正确处理所有可能的指令。在实现方式上,以x86架构为例,完全虚拟化经历了两个阶段:软件辅助的完全虚拟化和硬件辅助的完全虚拟化。
①软件实现的完全虚拟化
在x86虚拟化技术的早期,没有在硬件层次上对虚拟化提供支持,因此完全虚拟化只能通过软件实现。一个典型的做法是二进制代码翻译(Binary Translation)。
二进制代码翻译的思想是,通过扫描并修改客户机的二进制代码,将难以虚拟化的指令转化为支持虚拟化的指令。VMM通常会对操作系统的二进制代码进行扫描,一旦发现需要处理的指令,就将其翻译成为支持虚拟化的指令块(Cache Block)。这些指令块可以与VMM合作访问受限的虚拟资源,或者显式地触发异常让VMM进一步处理。
这种技术虽然能够实现完全虚拟化,但很难在架构上保证其完整性。因此,x86厂商在硬件上加入了对虚拟化的支持,从而在硬件架构上实现了虚拟化。
②硬件辅助完全虚拟化
可以预料,如果硬件本身加入足够的虚拟化功能,可以截获操作系统对敏感指令的执行或者对敏感资源的访问,从而通过异常的方式报告给VMM,这样就解决了虚拟化的问题。硬件虚拟化时一种完备的虚拟化方法,因而内存和外设的访问本身也是由指令来承载,对处理器指令级别的截获就意味着VMM可以模拟一个与真实主机完全一样的环境。
Intel的VT-x和AMD的AMD-V是这一方向的代表。以VT-x为例,其在处理器上引入了一个新的执行模式用于运行虚拟机,当虚拟机执行在这个特殊模式中时,它仍然面对的是一套完整的处理器寄存器集合和执行环境,只是任何敏感操作都会被处理器截获并报告给VMM。
在当前的系统级虚拟化解决方案中,全虚拟化应用得非常普遍,典型的有知名的产品有VirtualBox、KVM、VMware Workstation和VMware ESX(它在其4.0版,被改名为VMware vSphere)、Xen(也支持全虚拟化)。
(3)类虚拟化(Para-Virtualization)
这样的虚拟平台需要对所运行的客户机操作系统进行或多或少的修改使之适应虚拟环境,因此客户机操作系统知道其运行在虚拟平台上,并且会去主动适应。这种方式被称为类虚拟化,有时也称作半虚拟化。另外,值得指出的是,一个VMM可以既提供完全虚拟化的虚拟平台,又提供类虚拟化的虚拟平台。
类虚拟化是通过在源代码级别修改指令以回避虚拟化漏洞的方式来使VMM 能够对物理资源实现虚拟化。上面谈到x86 存在一些难以虚拟化的指令,完全虚拟化通过Binary Translation在二进制代码级别上来避免虚拟化漏洞。类虚拟化采取的是另一种思路,即修改操作系统内核的代码,使得操作系统内核完全避免这些难以虚拟化的指令。
既然内核代码已经需要修改,类虚拟化进一步可以被用于优化I/O。也就是说,类虚拟化不是去模拟真实世界中的设备,因为太多的寄存器模拟会降低性能.相反,类虚拟化可以自定义出高度优化的协议I/O。这种I/O协议完全基于事务,可以达到近似物理机的速度。
这种虚拟技术以Xen为代表,微软的Hyper-V所采用技术和Xen类似,也可以把Hyper-V归属于半虚拟化。
2.2.3 按照实现结构分类
在系统级虚拟化的实现中,VMM是一个关键角色,前面已介绍过VMM的组成部分。从Host实现VMM的角度出发,还可以将当前主流的虚拟化技术按照实现结构分为如下三类。
Hypervisor模型
Hypervisor这个术语是在 20 世纪 70 年代出现的,在早期计算机界,操作系统被称为Supervisor,因而能够在其他操作系统上运行的操作系统被称为 Hypervisor。
在Hypervisor模型中,VMM首先可以被看做是一个完备的操作系统,不过和传统操作系统不同的是,VMM是为虚拟化而设计的,因此还具备虚拟化功能。从架构上来看,首先,所有的物理资源如处理器、内存和I/O设备等都归VMM所有,因此,VMM承担着管理物理资源的责任;其次,VMM需要向上提供虚拟机用于运行客户机操作系统,因此,VMM还负责虚拟环境的创建和管理。
由于VMM同时具备物理资源的管理功能和虚拟化功能,因此,物理资源虚拟化的效率会更高一些。在安全方面,虚拟机的安全只依赖于VMM的安全。Hypervisor模型在拥有虚拟化高效率的同时也有其缺点。由于VMM完全拥有物理资源,因此,VMM需要进行物理资源的管理,包括设备的驱动。我们知道,设备驱动开发的工作量是很大的。因此,对于Hypervisor模型来说这是个很大的挑战。事实上,在实际的产品中,基于Hypervisor模型的VMM通常会根据产品定位,有选择地挑选一些I/O设备来支持,而不是支持所有的I/O设备。
采用这种模型的典型是面向企业级应用的VMware vSphere。
宿主模型
与Hypervisor模型不同。在宿主模型中,物理资源由宿主机操作系统管理。宿主机操作系统是传统操作系统,如Windows 、Linux等,这些传统操作系统并不是为虚拟化而设计的,因此本身并不具备虚拟化功能,实际的虚拟化功能由VMM来提供。VMM通常是宿主机操作系统独立的内核模块,有些实现中还包括用户态进程,如负责I/O虚拟化的用户态设备模型。 VMM通过调用宿主机操作系统的服务来获得资源, 实现处理器、内存和I/O设备的虚拟化。VMM创建出虚拟机之后,通常将虚拟机作为宿主机操作系统的一个进程参与调度。
宿主模型的优缺点和Hypervisor模型恰好相反。宿主模型最大的优点是可以充分利用现有操作系统的设备驱动程序,VMM无须为各类I/O设备重新实现驱动程序,可以专注于物理资源的虚拟化。考虑到I/O设备种类繁多,千变万化, 设备驱动程序开发的工作量非常大,因此,这个优点意义重大。此外,宿主模型也可以利用宿主机操作系统的其他功能,例如调度和电源管理等,这些都不需要VMM重新实现就可以直接使用。
宿主模型当然也有缺点,由于物理资源由宿主机操作系统控制,VMM得要调用宿主机操作系统的服务来获取资源进行虚拟化,而那些系统服务在设计开发之初并没有考虑虚拟化的支持,因此,VMM虚拟化的效率和功能会受到一定影响。此外,在安全方面,由于VMM是宿主机操作系统内核的一部分,因此,如果宿主机操作系统内核是不安全的,那么,VMM也是不安全的,相应地运行在虚拟机之上的客户机操作系统也是不安全的。换言之,虚拟机的安全不仅依赖于VMM的安全,也依赖于宿主机操作系统的安全。
采用这种模型的典型是KVM、VirtualBox和VMware Workstation。
混合模型
混合模型是上述两种模式的汇合体。VMM依然位于最低层,拥有所有的物理资源。与Hypervisor模式不同的是,VMM 会主动让出大部分I/O设备的控制权,将它们交由一个运行在特权虚拟机中的特权操作系统控制。相应地,VMM 虚拟化的职责也被分担.处理器和内存的虚拟化依然由VMM来完成,而I/O的虚拟化则由VMM和特权操作系统共同合作来完成。
I/O设备虚拟化由VMM和特权操作系统共同完成,因此,设备模型模块位于特权操作系统中,并且通过相应的通信机制与VMM合作。
混合模型集中了上述两种模型的优点。 VMM可以利用现有操作系统的I/O设备驱动程序,不需要另外开发。VMM直接控制处理器、内存等物理资源,虚拟化的效率也比较高。
在安全方面,如果对特权操作系统的权限控制得当,虚拟机的安全性只依赖于VMM。当然,混合模型也存在缺点。由于特权操作系统运行在虚拟机上,当需要特权操作系统提供服务时,VMM需要切换到特权操作系统,这里面就产生上下文切换的开销。当切换比较频繁时,上下文切换的开销会造成性能的明显下降。出于性能方面的考虑,很多功能还是必须在VMM 中实现,如调度程序和电源管理等。
采用这种模型的典型是Xen。
2.3 操作系统级虚拟化
在操作系统虚拟化技术中,每个节点上只有唯一的系统内核,不虚拟任何硬件设备。通过使用操作系统提供的功能,多个虚拟环境之间可以相互隔离。通常所说的容器(Container)技术,如目前为止最流行的容器系统Docker,即属于操作系统级虚拟化。此外,在不同的场景中,隔离出的虚拟环境也被称作虚拟环境(即VE,Virtual Environment)或虚拟专用服务器(即VPS,Virtual Private Server)。
以容器技术为例,它有自己独特的优点,它的出现,一方面解决了传统操作系统所忽视和缺乏的应用程序间的独立性问题,另一方面,它避免了相对笨重的系统级虚拟化,是一种轻量级的虚拟化解决方案。
操作系统领域一直以来面临的一个主要挑战来自于应用程序间存在的相互独立性和资源互操作性之间的矛盾,即每个应用程序都希望能运行在一个相对独立的系统环境下,不受到其他程序的干扰,同时又能以方便快捷的方式与其他程序交换和共享系统资源。当前通用操作系统更强调程序间的互操作性,而缺乏对程序间相对独立性的有效支持,然而对于许多分布式系统如Web服务、数据库、游戏平台等应用领域,提供高效的资源互操作同保持程序间的相对独立性具有同等重要的意义。
主流虚拟化产品VMware和Xen等均采用Hypervisor模型(Xen采用的混合模型与Hypervisor模型差别不大,可统称为Hypervisor模型)。该模型通过将应用程序运行在多个不同虚拟机内,实现对上层应用程序的隔离。但由于Hypervisor 模型倾向于每个虚拟机都拥有一份相对独立的系统资源,以提供更为完全的独立性,这种策略造成处于不同虚拟机内的应用程序间实现互操作非常困难。例如, 即使是运行在同一台物理机器上,如果处于不同虚拟机内,那么应用程序间仍然只能通过网络进行数据交换,而非共享内存或者文件。而如果使用容器技术,由于各容器共享同一个宿主操作系统,能够在满足基本的独立性需求的同时提供高效的系统资源共享支持。
容器技术还可以更高效地使用系统资源,由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销,相比虚拟机技术,一个相同配置的主机,往往可以运行更多数量的应用。此外,容器还具有更快速的启动时间,传统的虚拟机技术启动应用服务往往需要数分钟,而对于容器由于,直接运行于宿主内核,无需启动完整的操作系统,因此可以做到秒级、甚至毫秒级的启动时间,大大的节约了应用开发、测试、部署的时间。
3 典型虚拟化技术实现及其特点
3.1 系统级虚拟化实现
3.1.1 VMware
VMware是x86 虚拟化软件的主流广商之一。VMware的5位创始人中的3位曾在斯坦福大学研究操作系统虚拟化,项目包括SimOS系统模拟器和Disco虚拟机监控器。1998年,他们与另外两位创始人共同创建了VMware 公司,总部位于美国加州Palo Alto。
VMware提供一系列的虚拟化产品,产品的应用领域从服务器到桌面。下面是VMware主要产品的简介,包括VMware ESX、VMware Server和VMware Workstation。
VMware ESX Server是VMware的旗舰产品,后续版本改称VMware vSphere。ESX Server基于Hypervisor模型,在性能和安全性方面都得到了优化,是一款面向企业级应用的产品。VMware ESX Server支持完全虚拟化,可以运行Windows 、Linux、Solaris和Novell Netware等客户机操作系统。VMware ESX Server也支持类虚拟化,可以运行Linux 2. 6. 21 以上的客户机操作系统。ESX Server的早期版本采用软件虚拟化的方式,基于Binary Translation技术。自ESX Server 3开始采用硬件虚拟化的技术,支持Intel VT技术和AMD-V技术。
VMware Server之前叫VMware GSX Server,是VMware面向服务器端的入门级产品。VMware Server采用了宿主模型,宿主机操作系统可以是Windows或者Linux。VMware Server的功能与ESX Server类似,但是在性能和安全性上与ESX Server有所差距。VMware Server也有自己的优点,由于采用了宿主模型,因此VMware Server支持的硬件种类要比ESX Server多。
VMware Workstation是VMware面向桌面的主打产品。与VMware Server类似,VMware Workstation也是基于宿主模型,宿主机操作系统可以是Windows或者Linux。VMware Workstation也支持完全虚拟化,可以运行Windows、Linux、Solaris、Novell Netware和FreeBSD等客户机操作系统。与VMware Server不同, VMware Workstation专门针对桌面应用做了优化,如为虚拟机分配USB设备,为虚拟机显卡进行3D加速等。
3.1.2 Microsoft
微软在虚拟化产品方面起步比VMware晚,但是在认识到虚拟化的重要性之后,微软通过外部收购和内部开发,推出了一系列虚拟化产品,目前已经形成了比较完整的虚拟化产品线。微软的虚拟化产品涵盖了服务器虚拟化(Hyper-V)和桌面虚拟化(Virtual PC)。
Virtual PC是而向桌面的虚拟化产品,最早由Connectix公司开发,后来该产品被微软公司收购。Virtual PC是基于宿主模型的虚拟机产品,宿主机操作系统是Windows。早期版本也采用软件虚拟化方式,基于Binary Translation技术。之后版本已经支持硬件虚拟化技术。
Windows Server 2008是微软推出的服务器操作系统,其中一项重要的新功能是虚拟化功能。其虚拟化架构采用的是混合模型,重要组件之一Hyper-V作为Hypervisor运行在最底层,Server 2008本身作为特权操作系统运行在Hyper-V之上。Server 2008采用硬件虚拟化技术,必须运行在支持Intel VT技术或者AMD-V 技术的处理器上。
3.1.3 Xen
Xen是一款基于GPL授权方式的开源虚拟机软件。Xen起源于英国剑桥大学Ian Pratt领导的一个研究项目,之后,Xen独立出来成为一个社区驱动的开源软件项目。Xen社区吸引了许多公司和科研院所的开发者加入,发展非常迅速。之后,Ian成立了XenSource公司进行Xen的商业化应用,并且推出了基于Xen的产品Xen Server。2007年,Ctrix公司收购了XenSource公司,继续推广Xen的商业化应用,Xen开源项目本身则被独立到www.xen.org。
从技术角度来说,Xen基于混合模型,特权操作系统( 在Xen中称作Domain 0)可以是Linux、Solaris以及NetBSD,理论上,其他操作系统也可以移植作为Xen的特权操作系统。Xen最初的虚拟化思路是类虚拟化,通过修改Linux内核,实现处理器和内存的虚拟化,通过引入I/O的前端驱动/后端驱动(front / backend)架构实现设备的类虚拟化。之后也支持了完全虚拟化和硬件虚拟化技术。
3.1.4 KVM
KVM(Kernel-based Virtual Machine)也是一款基于GPL授权方式的开源虚拟机软件。KVM 最早由Qumranet公司开发,在2006年出现在Linux内核的邮件列表上,并于2007年被集成到了Linux 2.6.20内核中,成为内核的一部分。
KVM支持硬件虚拟化方法,并结合QEMU来提供设备虚拟化。KVM的特点在于和Linux内核结合得非常好,而且和Xen一样,作为开源软件,KVM的移植性也很好。
3.1.5 Oracle VM VirtualBox
VirtualBox是一款开源虚拟机软件,类似于VMware Workstation。VirtualBox 是由德国Innotek公司开发,由Sun Microsystems公司出品的软件,使用Qt编写,在 Sun 被 Oracle 收购后正式更名成 Oracle VM VirtualBox。Innotek 以 GNU General Public License (GPL) 释出 VirtualBox。用户可以在VirtualBox上安装并且执行Solaris、Windows、DOS、Linux、BSD等系统作为客户端操作系统。现在由甲骨文公司进行开发,是甲骨文公司VM虚拟化平台技术的一部分。
3.1.6 Bochs
Bochs 是一个 x86 计算机仿真器,它在很多平台上(包括 x86、PowerPC、Alpha、SPARC 和 MIPS)都可以移植和运行。使 Bochs 不仅可以对处理器进行仿真,还可以对整个计算机进行仿真,包括计算机的外围设备,比如键盘、鼠标、视频图像硬件、网卡(NIC)等。
Bochs 可以配置作为一个老式的 Intel® 386 或其后继处理器使用,例如 486、Pentium、Pentium Pro 或 64 位处理器。它甚至还可以对一些可选的图形指令进行仿真,例如 MMX 和 3DNow。
3.1.7 QEMU
QEMU是一套由Fabrice Bellard所编写的模拟处理器的自由软件。它与Bochs,PearPC近似,但其具有某些后两者所不具备的特性,如高速度及跨平台的特性,qemu可以虚拟出不同架构的虚拟机,如在x86平台上可以虚拟出power机器。kqemu为qemu的加速器,经由kqemu这个开源的加速器,QEMU能模拟至接近真实电脑的速度。
QEMU本身可以不依赖于KVM,但是如果有 KVM的存在并且硬件(处理器)支持比如Intel VT功能,那么QEMU在对处理器虚拟化这一块可以利用KVM提供的功能来提升性能。换言之,KVM缺乏设备虚拟化以及相应的用户空间管理虚拟机的工具,所以它借用了QEMU的代码并加以精简,连同KVM一起构成了一个完整的虚拟化解决方案,不妨称之为:KVM+QEMU。
3.2 操作系统级虚拟化实现
3.2.1 chroot
容器的概念始于 1979 年的 UNIX chroot,它是一个 UNIX 操作系统上的系统调用,用于将一个进程及其子进程的根目录改变到文件系统中的一个新位置,让这些进程只能访问到该目录。这个功能的想法是为每个进程提供独立的磁盘空间。其后在 1982年,它被加入到了 BSD 系统中。
3.2.2 LXC
LXC 的意思是 LinuX Containers,它是第一个最完善的 Linux 容器管理器的实现方案,是通过 cgroups 和 Linux 名字空间namespace实现的。LXC 存在于 liblxc 库中,提供了各种编程语言的 API 实现,包括 Python3、Python2、Lua、Go、Ruby 和 Haskell 等。与其它容器技术不同的是, LXC 可以工作在普通的 Linux 内核上,而不需要增加补丁。现在 LXC project 是由 Canonical 公司赞助并托管的。
3.2.3 Docker
Docker 是到现在为止最流行和使用广泛的容器管理系统。它最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目,后来该公司改名为 Docker。Docker 开始阶段使用的也是 LXC ,之后采用自己开发的 libcontainer 替代了它。不像其它的容器平台,Docker 引入了一整个管理容器的生态系统,这包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰的 REST API、命令行等等。稍后的阶段, Docker 推动实现了一个叫做 Docker Swarm 的容器集群管理方案。
3.2.4 Linux VServer
Linux-VServer 也是一个操作系统级虚拟化解决方案。Linux-VServer 对 Linux 内核进行虚拟化,这样多个用户空间环境—又称为 Virtual Private Server(VPS) 就可以单独运行,而不需要互相了解。Linux-VServer 通过修改 Linux 内核实现用户空间的隔离。
Linux-VServer 也使用了 chroot 来为每个 VPS 隔离 root 目录。虽然 chroot 允许指定新 root 目录,但还是需要其他一些功能(称为 Chroot-Barrier)来限制 VPS 脱离其隔离的 root 目录回到上级目录。给定一个隔离的 root 目录之后,每个 VPS 就可以拥有自己的用户列表和 root 密码。
2.4 和 2.6 版本的 Linux 内核支持 Linux-VServer,它可以运行于很多平台之上,包括 x86、x86-64、SPARC、MIPS、ARM 和 PowerPC。
3.2.5 Virtuozzo/OpenVZ
Virtuozzo是SWsoft公司(目前SWsoft已经改名为Parallels)的操作系统虚拟化软件的命名,Virtuozzo是商业解决方案,而OpenVZ是以Virtuozzo为基础的开源项目,它们采用的也是操作系统级虚拟化技术。OpenVZ 类似于 Linux-VServer,它通过对 Linux 内核进行补丁来提供虚拟化、隔离、资源管理和状态检查。每个 OpenVZ 容器都有一套隔离的文件系统、用户及用户组等。
参考文献
1 ] 金海, 廖小飞. 面向计算系统的虚拟化技术J]. 中国基础科学, 2008, 10(6):12-18.
2 ] 英特尔开源软件技术中心. 系统虚拟化M]. 清华大学出版社, 2009.
3 ] GeorgeCoulouris, 库鲁里斯, 金蓓弘,等. 分布式系统:分布式系统概念与设计M]. 机械工业出版社, 2013
4 ] Andrew S. Tanenbaum, Maarten van Steen. 分布式系统原理与范型M]. 清华大学出版社, 2004.
5 ] Barham P, Dragovic B, Fraser K, et al. Virtual machine monitors: Xen and the art of virtualizationJ]. Symposium on Operating System Principles, 2003, 36(August):164–177.
6 ] Qumranet A K, Qumranet Y K, Qumranet D L, et al. kvm: the Linux virtual machine monitorJ]. Proc Linux Symposium, 2007.
7 ] Adams K, Agesen O. A comparison of software and hardware techniques for x86 virtualizationC]// ACM, 2006:2-13.
8 ] Uhlig R, Neiger G, Rodgers D, et al. Intel virtualization technologyJ]. Computer, 2005, 38(5):48-56.
9 ] Garfinkel T, Rosenblum M. A Virtual Machine Introspection Based Architecture for Intrusion DetectionJ]. Proceedings of the Network & Distributed Systems Security Symposium, 2003:191–206.