安卓模拟器的虚拟化技术是什么，它有什么历史和价值
虚拟化技术（VT）其实不是安卓模拟器专用的 很多专业的电脑软件都会要求或者建议你开VT 甚至你电脑刚买回来就已经开了VT的 开了VT在对模拟器的使用上会让模拟器获得更大内存和核数 更加迅速地处理数据 因此玩游戏的时候会更加流畅
谁提出了存储虚拟化的概念？
随着围绕数字化、网络化开展的各种多媒体处理业务的不断增加，存储系统网络平台已经成为一个核心平台，同时各种应用对平台的要求也越来越高，不光是在存储容量上，还包括数据访问性能、数据传输性能、数据管理能力、存储扩展能力等等多个方面。可以说，存储网络平台的综合性能的优劣，将直接影响到整个系统的正常运行。
为达到这些要求，一种新兴的技术正越来越受到大家的关注，即虚拟存储技术。
其实虚拟化技术并不是一件很新的技术，它的发展，应该说是随着计算机技术的发展而发展起来的，最早是始于70年代。由于当时的存储容量，特别是内存容量成本非常高、容量也很小，对于大型应用程序或多程序应用就受到了很大的限制。为了克服这样的限制，人们就采用了虚拟存储的技术，最典型的应用就是虚拟内存技术。随着计算机技术以及相关信息处理技术的不断发展，人们对存储的需求越来越大。这样的需求刺激了各种新技术的出现，比如磁盘性能越来越好、容量越来越大。但是在大量的大中型信息处理系统中，单个磁盘是不能满足需要，这样的情况下存储虚拟化技术就发展起来了。在这个发展过程中也由几个阶段和几种应用。首先是磁盘条带集（RAID，可带容错）技术，将多个物理磁盘通过一定的逻辑关系集合起来，成为一个大容量的虚拟磁盘。而随着数据量不断增加和对数据可用性要求的不断提高，又一种新的存储技术应运而生，那就是存储区域网络（SAN）技术。SAN的广域化则旨在将存储设备实现成为一种公用设施，任何人员、任何主机都可以随时随地获取各自想要的数据。目前讨论比较多的包括iSCSI、FC Over IP 等技术，由于一些相关的标准还没有最终确定，但是存储设备公用化、存储网络广域化是一个不可逆转的潮流。
一、虚拟存储的概念
所谓虚拟存储，就是把多个存储介质模块（如硬盘、RAID）通过一定的手段集中管理起来，所有的存储模块在一个存储池（Storage Pool）中得到统一管理，从主机和工作站的角度，看到就不是多个硬盘，而是一个分区或者卷，就好象是一个超大容量（如1T以上）的硬盘。这种可以将多种、多个存储设备统一管理起来，为使用者提供大容量、高数据传输性能的存储系统，就称之为虚拟存储。
二、虚拟存储的分类
目前虚拟存储的发展尚无统一标准，从虚拟化存储的拓扑结构来讲主要有两种方式：即对称式与非对称式。对称式虚拟存储技术是指虚拟存储控制设备与存储软件系统、交换设备集成为一个整体，内嵌在网络数据传输路径中；非对称式虚拟存储技术是指虚拟存储控制设备独立于数据传输路径之外。从虚拟化存储的实现原理来讲也有两种方式；即数据块虚拟与虚拟文件系统。具体如下：
1．对称式虚拟存储
图1对称式虚拟存储解决方案的示意图
在图1所示的对称式虚拟存储结构图中，存储控制设备 High Speed Traffic Directors（HSTD）与存储池子系统Storage Pool集成在一起，组成SAN Appliance。可以看到在该方案中存储控制设备HSTD在主机与存储池数据交换的过程中起到核心作用。该方案的虚拟存储过程是这样的：由HSTD内嵌的存储管理系统将存储池中的物理硬盘虚拟为逻辑存储单元（LUN），并进行端口映射（指定某一个LUN能被哪些端口所见），主机端将各可见的存储单元映射为操作系统可识别的盘符。当主机向SAN Appliance写入数据时，用户只需要将数据写入位置指定为自己映射的盘符（LUN），数据经过HSTD的高速并行端口，先写入高速缓存，HSTD中的存储管理系统自动完成目标位置由LUN到物理硬盘的转换，在此过程中用户见到的只是虚拟逻辑单元，而不关心每个LUN的具体物理组织结构。该方案具有以下主要特点：
（1）采用大容量高速缓存，显著提高数据传输速度。
缓存是存储系统中广泛采用的位于主机与存储设备之间的I/O路径上的中间介质。当主机从存储设备中读取数据时，会把与当前数据存储位置相连的数据读到缓存中，并把多次调用的数据保留在缓存中；当主机读数据时，在很大几率上能够从缓存中找到所需要的数据。直接从缓存上读出。而从缓存读取数据时的速度只受到电信号传播速度的影响（等于光速），因此大大高于从硬盘读数据时盘片机械转动的速度。当主机向存储设备写入数据时，先把数据写入缓存中，待主机端写入动作停止，再从缓存中将数据写入硬盘，同样高于直接写入硬盘的速度
（2）多端口并行技术，消除了I/O瓶颈。
传统的FC存储设备中控制端口与逻辑盘之间是固定关系，访问一块硬盘只能通过控制它的控制器端口。在对称式虚拟存储设备中，SAN Appliance的存储端口与LUN的关系是虚拟的，也就是说多台主机可以通过多个存储端口（最多8个）并发访问同一个LUN；在光纤通道100MB/带宽的大前提下，并行工作的端口数量越多，数据带宽就越高。
（3）逻辑存储单元提供了高速的磁盘访问速度。
在视频应用环境中，应用程序读写数据时以固定大小的数据块为单位（从512byte到1MB之间）。而存储系统为了保证应用程序的带宽需求，往往设计为传输512byte以上的数据块大小时才能达到其最佳I/O性能。在传统SAN结构中，当容量需求增大时，唯一的解决办法是多块磁盘（物理或逻辑的）绑定为带区集，实现大容量LUN。在对称式虚拟存储系统中，为主机提供真正的超大容量、高性能LUN，而不是用带区集方式实现的性能较差的逻辑卷。与带区集相比，Power LUN具有很多优势，如大块的I/O block会真正被存储系统所接受，有效提高数据传输速度；并且由于没有带区集的处理过程，主机CPU可以解除很大负担，提高了主机的性能。
（4）成对的HSTD系统的容错性能。
在对称式虚拟存储系统中，HSTD是数据I/O的必经之地，存储池是数据存放地。由于存储池中的数据具有容错机制保障安全，因此用户自然会想到HSTD是否有容错保护。象许多大型存储系统一样，在成熟的对称式虚拟存储系统中，HSTD是成对配制的，每对HSTD之间是通过SAN Appliance内嵌的网络管理服务实现缓存数据一致和相互通信的。
（5）在SAN Appliance之上可方便的连接交换设备，实现超大规模Fabric结构的SAN。
因为系统保持了标准的SAN结构，为系统的扩展和互连提供了技术保障，所以在SAN Appliance之上可方便的连接交换设备，实现超大规模Fabric结构的SAN。
2．非对称式虚拟存储系统
图2非对称式虚拟存储系统示意图
在图2所示的非对称式虚拟存储系统结构图中，网络中的每一台主机和虚拟存储管理设备均连接到磁盘阵列，其中主机的数据路径通过FC交换设备到达磁盘阵列；虚拟存储设备对网络上连接的磁盘阵列进行虚拟化操作，将各存储阵列中的LUN虚拟为逻辑带区集（Strip）,并对网络上的每一台主机指定对每一个Strip的访问权限（可写、可读、禁止访问）。当主机要访问某个Strip时，首先要访问虚拟存储设备，读取Strip信息和访问权限，然后再通过交换设备访问实际的Strip中的数据。在此过程中，主机只会识别到逻辑的Strip，而不会直接识别到物理硬盘。这种方案具有如下特点：
（1）将不同物理硬盘阵列中的容量进行逻辑组合，实现虚拟的带区集，将多个阵列控制器端口绑定，在一定程度上提高了系统的可用带宽。
（2）在交换机端口数量足够的情况下，可在一个网络内安装两台虚拟存储设备，实现Strip信息和访问权限的冗余。
但是该方案存在如下一些不足：
（1）该方案本质上是带区集——磁盘阵列结构，一旦带区集中的某个磁盘阵列控制器损坏，或者这个阵列到交换机路径上的铜缆、GBIC损坏，都会导致一个虚拟的LUN离线，而带区集本身是没有容错能力的，一个LUN的损坏就意味着整个Strip里面数据的丢失。
（2）由于该方案的带宽提高是通过阵列端口绑定来实现的，而普通光纤通道阵列控制器的有效带宽仅在40MB/S左右，因此要达到几百兆的带宽就意味着要调用十几台阵列，这样就会占用几十个交换机端口，在只有一两台交换机的中小型网络中，这是不可实现的。
（3）由于各种品牌、型号的磁盘阵列其性能不完全相同，如果出于虚拟化的目的将不同品牌、型号的阵列进行绑定，会带来一个问题：即数据写入或读出时各并发数据流的速度不同，这就意味着原来的数据包顺序在传输完毕后被打乱，系统需要占用时间和资源去重新进行数据包排序整理，这会严重影响系统性能。
3．数据块虚拟与虚拟文件系统
以上从拓扑结构角度分析了对称式与非对称式虚拟存储方案的异同，实际从虚拟化存储的实现原理来讲也有两种方式；即数据块虚拟与虚拟文件系统。
数据块虚拟存储方案着重解决数据传输过程中的冲突和延时问题。在多交换机组成的大型Fabric结构的SAN中，由于多台主机通过多个交换机端口访问存储设备，延时和数据块冲突问题非常严重。数据块虚拟存储方案利用虚拟的多端口并行技术，为多台客户机提供了极高的带宽，最大限度上减少了延时与冲突的发生，在实际应用中，数据块虚拟存储方案以对称式拓扑结构为表现形式。
虚拟文件系统存储方案着重解决大规模网络中文件共享的安全机制问题。通过对不同的站点指定不同的访问权限，保证网络文件的安全。在实际应用中，虚拟文件系统存储方案以非对称式拓扑结构为表现形式。
三、虚拟存储技术的实现方式
目前实现虚拟存储主要分为如下几种：
1．在服务器端的虚拟存储
服务器厂商会在服务器端实施虚拟存储。同样，软件厂商也会在服务器平台上实施虚拟存储。这些虚拟存储的实施都是通过服务器端将镜像映射到外围存储设备上，除了分配数据外，对外围存储设备没有任何控制。服务器端一般是通过逻辑卷管理来实现虚拟存储技术。逻辑卷管理为从物理存储映射到逻辑上的卷提供了一个虚拟层。服务器只需要处理逻辑卷，而不用管理存储设备的物理参数。
用这种构建虚拟存储系统，服务器端是一性能瓶颈，因此在多媒体处理领域几乎很少采用。
2．在存储子系统端的虚拟存储
另一种实施虚拟的地方是存储设备本身。这种虚拟存储一般是存储厂商实施的，但是很可能使用厂商独家的存储产品。为避免这种不兼容性，厂商也许会和服务器、软件或网络厂商进行合作。当虚拟存储实施在设备端时，逻辑（虚拟）环境和物理设备同在一个控制范围中，这样做的益处在于：虚拟磁盘高度有效地使用磁盘容量，虚拟磁带高度有效地使用磁带介质。
在存储子系统端的虚拟存储设备主要通过大规模的RAID子系统和多个I/O通道连接到服务器上，智能控制器提供LUN访问控制、缓存和其他如数据复制等的管理功能。这种方式的优点在于存储设备管理员对设备有完全的控制权，而且通过与服务器系统分开，可以将存储的管理与多种服务器操作系统隔离，并且可以很容易地调整硬件参数。
3．网络设备端实施虚拟存储
网络厂商会在网络设备端实施虚拟存储，通过网络将逻辑镜像映射到外围存储设备，除了分配数据外，对外围存储设备没有任何控制。在网络端实施虚拟存储具有其合理性，因为它的实施既不是在服务器端，也不是在存储设备端，而是介于两个环境之间，可能是最“开放”的虚拟实施环境，最有可能支持任何的服务器、操作系统、应用和存储设备。从技术上讲，在网络端实施虚拟存储的结构形式有以下两种：即对称式与非对称式虚拟存储。
从目前的虚拟存储技术和产品的实际情况来看，基于主机和基于存储的方法对于初期的采用者来说魅力最大，因为他们不需要任何附加硬件，但对于异构存储系统和操作系统而言，系统的运行效果并不是很好。基于互联设备的方法处于两者之间，它回避了一些安全性问题，存储虚拟化的功能较强，能减轻单一主机的负载，同时可获得很好的可扩充性。
不管采用何种虚拟存储技术，其目的都使为了提供一个高性能、安全、稳定、可靠、可扩展的存储网络平台，满足节目制作网络系统的苛刻要求。根据综合的性能价格比来说，一般情况下，在基于主机和基于存储设备的虚拟存储技术能够保证系统的数据处理能力要求时，优先考虑，因为这两种虚拟存储技术构架方便、管理简单、维护容易、产品相对成熟、性能价格比高。在单纯的基于存储设备的虚拟存储技术无法保证存储系统性能要求的情况下，我们可以考虑采用基于互连设备的虚拟存储技术。
四、虚拟存储的特点
虚拟存储具有如下特点：
（1）虚拟存储提供了一个大容量存储系统集中管理的手段，由网络中的一个环节（如服务器）进行统一管理，避免了由于存储设备扩充所带来的管理方面的麻烦。例如，使用一般存储系统，当增加新的存储设备时，整个系统（包括网络中的诸多用户设备）都需要重新进行繁琐的配置工作，才可以使这个“新成员”加入到存储系统之中。而使用虚拟存储技术，增加新的存储设备时，只需要网络管理员对存储系统进行较为简单的系统配置更改，客户端无需任何操作，感觉上只是存储系统的容量增大了。
（2）虚拟存储对于视频网络系统最有价值的特点是：可以大大提高存储系统整体访问带宽。存储系统是由多个存储模块组成，而虚拟存储系统可以很好地进行负载平衡，把每一次数据访问所需的带宽合理地分配到各个存储模块上，这样系统的整体访问带宽就增大了。例如，一个存储系统中有4个存储模块，每一个存储模块的访问带宽为50MBps，则这个存储系统的总访问带宽就可以接近各存储模块带宽之和，即200MBps。
（3）虚拟存储技术为存储资源管理提供了更好的灵活性，可以将不同类型的存储设备集中管理使用，保障了用户以往购买的存储设备的投资。
（4）虚拟存储技术可以通过管理软件，为网络系统提供一些其它有用功能，如无需服务器的远程镜像、数据快照(Snapshot)等。
五、虚拟存储的应用 由于虚拟存储具有上述特点，虚拟存储技术正逐步成为共享存储管理的主流技术，其应用具体如下：
1．数据镜像
数据镜像就是通过双向同步或单向同步模式在不同的存储设备间建立数据复本。一个合理的解决方案应该能在不依靠设备生产商及操作系统支持的情况下，提供在同一存储阵列及不同存储阵列间制作镜像的方法。
2．数据复制
通过IP地址实现的远距离数据迁移（通常为异步传输）对于不同规模的企业来说，都是一种极为重要的数据灾难恢复工具。好的解决方案不应当依赖特殊的网络设备支持，同时，也不应当依赖主机，以节省企业的管理费用。
3．磁带备份增强设备
过去的几年，在磁带备份技术上鲜有新发展。尽管如此，一个网络存储设备平台亦应能在磁带和磁盘间搭建桥路，以高速、平稳、安全地完成备份工作。
4．实时复本
出于测试、拓展及汇总或一些别的原因，企业经常需要制作数据复本。
5．实时数据恢复
利用磁带来还原数据是数据恢复工作的主要手段，但常常难以成功。数据管理工作其中一个重要的发展新方向是将近期内的备分数据（可以是数星期前的历史数据）转移到磁盘介质，而非磁带介质。用磁盘恢复数据就象闪电般迅速（所有文件能在60秒内恢复），并远比用磁带恢复数据安全可靠。同时，整卷（Volume）数据都能被恢复。
6．应用整合
存储管理发展的又一新方向是，将服务贴近应用。没有一个信息技术领域的管理人员会单纯出于对存储设备的兴趣而去购买它。存储设备是用来服务于应用的，比如数据库，通讯系统等等。通过将存储设备和关键的企业应用行为相整合，能够获取更大的价值，同时，大大减少操作过程中遇到的难题。
7．虚拟存储在数字视频网络中的应用
现在我着重介绍虚拟存储在数字视频网络中的应用。
数字视频网络对广播电视行业来说已经不是一个陌生的概念了，由于它在广播电视技术数字化进程中起到了重要的作用，国内各级电视台对其给予极大的关注，并且开始构造和应用这类系统，在数字视频网的概念中完全打破了以往一台录象机、一个编辑系统、一套播出系统的传统结构，而代之以上载工作站、编辑制作工作站、播出工作站及节目存储工作站的流程，便于操作和管理。节目上载、节目编辑、节目播出在不同功能的工作站上完成，可成倍提高工作效率。同时，由于采用非线性编辑系统，除了采集时的压缩损失外。信号在制作、播出过程中不再有任何损失，节目的技术质量将大大提高。
在现有的视频网络系统中，虽然电脑的主频、网络的传输速率以及交换设备的性能，已经可以满足绝大多数应用的要求，但其中存储设备的访问带宽问题成为了系统的一个主要性能瓶颈。视频编辑、制作具有数据量存储大、码流高、实时性强、安全性重要等特点。这就要求应用于视频领域的存储技术和产品必须具有足够的带宽并且稳定性要好。
在单机应用时，为了保证一台编辑站点有足够的数据带宽，SCSI技术、本地独立磁盘冗余阵例RAID（Redundant Array of Independent Disks）技术（包括软件和硬件）被广泛应用，它通过把若干个SCSI硬盘加上控制器组成一个大容量，快速响应，高可靠性的存储子系统，从用户看可作为一个逻辑盘或者虚拟盘，从而大大提高了数据传输率和存储容量，同时利用纠错技术提高了存储的可靠性，并可满足带宽要求。
随着节目制作需求的发展，要求2—3台站点共享编辑数据。这时可利用SCSI网络技术实现这一要求。几台编辑站点均配置高性能的SCSI适配器，连接至共享的SCSI磁盘阵列，既可以实现几个站点共享数据，又可以保证每一台单机的工作带宽。
光纤通道技术的成熟应用对视频网络的发展具有里程碑的意义，从此主机与共享存储设备之间的连接距离限制从几米、十几米，扩展到几百米、几千米，再配合光纤通道交换设备，网络规模得到几倍、十几倍的扩充。这时候的FC（Fibre Channel光纤通道）磁盘阵列——RAID容错技术、相对SCSI的高带宽、大容量，成为视频网络中的核心存储设备。
随着电视台规模的发展，全台级大规模视频网络的应用被提出。在这种需求下，就必须将更先进的存储技术与产品引入视频领域。存储区域网（SAN）的发展目前正处于全速上升期，各种概念层出不穷。其中具有划时代意义的是虚拟存储概念的提出。相对于传统的交换机加RAID阵列，主机通过硬件层直接访问阵列中的硬盘的SAN结构，虚拟存储的定位是将数据存储功能从实际的、物理的数据存取过程中抽象出来，使普通用户在访问数据时不必关心具体的存储设备的配置参数、物理位置及容量，从而简化用户和系统管理人员的工作难度。
在设计一个视频网络系统的时候，对存储系统的选用，主要考虑如下几个因素：（1）总体带宽性能；（2）可管理性；（3）安全性；（4）可扩展性；（5）系统成本。
当然，这些因素之间有时是相互制约的，特别是系统成本与性能和安全性的关系。如何在这些因素之间寻求合理的、实用的、经济的配合，是一个需要解决的课题。虚拟存储技术的出现，为我们在构建视频网络系统时提供了一个切实可行的高性能价格比的解决方案。
从拓扑结构来讲，对称式的方案具有更高的带宽性能，更好的安全特性，因此比较适合大规模视频网络应用。非对称式方案由于采用了虚拟文件原理，因此更适合普通局域网（如办公网）的应用。
常见的虚拟化技术
虚拟化技术有哪些
1、CPU虚拟化
虚拟化在计算机方面通常是指计算元件在虚拟的基础上而不是真实的基础上运行。虚拟化技术可以扩大硬件的容量，简化软件的重新配置过程。简单说来，CPU的虚拟化技术就是单CPU模拟多CPU并行，允许一个平台同时运行多个操作系统，并且应用程序都可以在相互独立的空间内运行而互不影响，从而显著提高计算机的工作效率。
2、网络虚拟化
网络虚拟化是目前业界关于虚拟化细分领域界定最不明确，存在争议较多的一个概念。微软眼中的“网络虚拟化”，是指虚拟专用网络（VPN）。VPN对网络连接的概念进行了抽象，允许远程用户访问组织的内部网络，就像物理上连接到该网络一样。网络虚拟化可以帮助保护IT环境，防止来自Internet的威胁，同时使用户能够快速安全的访问应用程序和数据。
3、服务器虚拟化
与网络虚拟化不同，服务器虚拟化却是虚拟化技术最早细分出来的子领域。根据2006年2月ForresterResearch的调查，全球范围的企业对服务器虚拟化的认知率达到了75%。三分之一的企业已经在使用或者准备部署服务器虚拟化。这个产生于20世纪60年代的技术日益显示出其重要价值。由于服务器虚拟化发展时间长，应用广泛，所以很多时候人们几乎把服务器虚拟化等同于虚拟化。
4、存储虚拟化
随着信息业务的不断运行和发展，存储系统网络平台已经成为一个核心平台，大量高价值数据积淀下来，围绕这些数据的应用对平台的要求也越来越高，不光是在存储容量上，还包括数据访问性能、数据传输性能、数据管理能力、存储扩展能力等等多个方面。可以说，存储网络平台的综合性能的优劣，将直接影响到整个系统的正常运行。因为这个原因，虚拟化技术又一子领域——虚拟存储技术，应运而生。
5、应用虚拟化
前面几种虚拟化技术，主要还专注于对硬件平台资源的虚拟优化分配，随着IT应用的日益广泛，应用虚拟化作为虚拟化家族的明日之星登上了历史舞台。2006年7月由Forrester咨询公司在美国对各种不同行业的高层IT管理人员所做的一项研究显示，当今的机构现在将应用虚拟化当作是业务上的一个必由之路，而不是一个IT决策。据统计，全世界目前至少有超过18万个机构在利用应用虚拟化技术进行集中IT管理、加强安全性和减少总体成本。
虚拟化有哪些应用？
近年来，云原生 （Cloud Native）可谓是 IT 界最火的概念之一，众多互联网巨头都已经开始积极拥抱云原生。而说到云原生，我们就不得不了解本文的主角 —— 容器（container）。容器技术可谓是撑起了云原生生态的半壁江山。容器作为一种先进的虚拟化技术，已然成为了云原生时代软件开发和运维的标准基础设施，在了解它之前，我们不妨从虚拟化技术说起。
何谓虚拟化技术
1961 年 —— IBM709 机实现了分时系统
计算机历史上首个虚拟化技术实现于 1961 年，IBM709 计算机首次将 CPU 占用切分为多个极短 (1/100sec) 时间片，每一个时间片都用来执行着不同的任务。通过对这些时间片的轮询，这样就可以将一个 CPU 虚拟化或者伪装成为多个 CPU，并且让每一颗虚拟 CPU 看起来都是在同时运行的。这就是虚拟机的雏形。
容器的功能其实和虚拟机类似，无论容器还是虚拟机，其实都是在计算机不同的层面进行虚拟化，即使用逻辑来表示资源，从而摆脱物理限制的约束，提高物理资源的利用率。虚拟化技术是一个抽象又内涵丰富的概念，在不同的领域或层面有着不同的含义。
这里我们首先来粗略地讲讲计算机的层级结构。计算机系统对于大部分软件开发者来说可以分为以下层级结构：
应用程序层
函数库层
操作系统层
硬件层
各层级自底向上，每一层都向上提供了接口，同时每一层也只需要知道下一层的接口即可调用底层功能来实现上层操作（不需要知道底层的具体运作机制）。
但由于早期计算机厂商生产出来的硬件遵循各自的标准和规范，使得操作系统在不同计算机硬件之间的兼容性很差；同理，不同的软件在不同的操作系统下的兼容性也很差。于是，就有开发者人为地在层与层之间创造了抽象层：
应用层
函数库层
API抽象层
操作系统层
硬件抽象层
硬件层
就我们探讨的层面来说，所谓虚拟化就是在上下两层之间，人为地创造出一个新的抽象层，使得上层软件可以直接运行在新的虚拟环境上。简单来说，虚拟化就是通过模访下层原有的功能模块创造接口，来“欺骗”上层，从而达到跨平台开发的目的。
综合上述理念，我们就可以重新认识如今几大广为人知的虚拟化技术：
虚拟机：存在于硬件层和操作系统层间的虚拟化技术。
虚拟机通过“伪造”一个硬件抽象接口，将一个操作系统以及操作系统层以上的层嫁接到硬件上，实现和真实物理机几乎一样的功能。比如我们在一台 Windows 系统的电脑上使用 Android 虚拟机，就能够用这台电脑打开 Android 系统上的应用。
容器：存在于操作系统层和函数库层之间的虚拟化技术。
容器通过“伪造”操作系统的接口，将函数库层以上的功能置于操作系统上。以 Docker 为例，其就是一个基于 Linux 操作系统的 Namespace 和 Cgroup 功能实现的隔离容器，可以模拟操作系统的功能。简单来说，如果虚拟机是把整个操作系统封装隔离，从而实现跨平台应用的话，那么容器则是把一个个应用单独封装隔离，从而实现跨平台应用。所以容器体积比虚拟机小很多，理论上占用资源更少。
JVM：存在于函数库层和应用程序之间的虚拟化技术。
Java 虚拟机同样具有跨平台特性，所谓跨平台特性实际上也就是虚拟化的功劳。我们知道 Java 语言是调用操作系统函数库的，JVM 就是在应用层与函数库层之间建立一个抽象层，对下通过不同的版本适应不同的操作系统函数库，对上提供统一的运行环境交给程序和开发者，使开发者能够调用不同操作系统的函数库。
在大致理解了虚拟化技术之后，接下来我们就可以来了解容器的诞生历史。虽然容器概念是在 Docker 出现以后才开始在全球范围内火起来的，但在 Docker 之前，就已经有无数先驱在探索这一极具前瞻性的虚拟化技术。
容器的前身 “Jail”
1979 年 —— 贝尔实验室发明 chroot
容器主要的特性之一就是进程隔离。早在 1979 年，贝尔实验室在 Unix V7 的开发过程中，发现当一个系统软件编译和安装完成后，整个测试环境的变量就会发生改变，如果要进行下一次构建、安装和测试，就必须重新搭建和配置测试环境。要知道在那个年代，一块 64K 的内存条就要卖 419 美元，“快速销毁和重建基础设施”的成本实在是太高了。
开发者们开始思考，能否在现有的操作系统环境下，隔离出一个用来重构和测试软件的独立环境？于是，一个叫做 chroot（Change Root）的系统调用功能就此诞生。
chroot 可以重定向进程及其子进程的 root 目录到文件系统上的新位置，也就是说使用它可以分离每个进程的文件访问权限，使得该进程无法接触到外面的文件，因此这个被隔离出来的新环境也得到了一个非常形象的命名，叫做 Chroot Jail （监狱）。之后只要把需要的系统文件一并拷贝到 Chroot Jail 中，就能够实现软件重构和测试。这项进步开启了进程隔离的大门，为 Unix 提供了一种简单的系统隔离功能，尤其是 jail 的思路为容器技术的发展奠定了基础。但是此时 chroot 的隔离功能仅限于文件系统，进程和网络空间并没有得到相应的处理。
进入21世纪，此时的虚拟机（VM）技术已经相对成熟，人们可以通过虚拟机技术实现跨操作系统的开发。但由于 VM 需要对整个操作系统进行封装隔离，占用资源很大，在生产环境中显得太过于笨重。于是人们开始追求一种更加轻便的虚拟化技术，众多基于 chroot 扩展实现的进程隔离技术陆续诞生。
2000 年 —— FreeBSD 推出 FreeBSD Jail
在 chroot 诞生 21 年后，FreeBSD 4.0 版本推出了一套微型主机环境共享系统 FreeBSD Jail，将 chroot 已有的机制进行了扩展。在 FreeBSD Jail 中，程序除了有自己的文件系统以外，还有独立的进程和网络空间，Jail 中的进程既不能访问也不能看到 Jail 之外的文件、进程和网络资源。
2001 年 —— Linux VServer 诞生
2001年，Linux 内核新增 Linux VServer（虚拟服务器），为 Linux 系统提供虚拟化功能。Linux VServer 采取的也是一种 jail 机制，它能够划分计算机系统上的文件系统、网络地址和内存，并允许一次运行多个虚拟单元。
2004 年 —— SUN 发布 Solaris Containers
该技术同样由 chroot 进一步发展而来。2004 年 2 月，SUN 发布类 Unix 系统 Solaris 的 10 beta 版，新增操作系统虚拟化功能 Container，并在之后的 Solaris 10 正式版中完善。Solaris Containers 支持 x86 和 SPARC 系统，SUN 创造了一个 zone 功能与 Container 配合使用，前者是一个单一操作系统中完全隔离的虚拟服务器，由系统资源控制和 zones 提供的边界分离实现进程隔离。
2005 年 —— OpenVZ 诞生
类似于 Solaris Containers，它通过对 Linux 内核进行补丁来提供虚拟化、隔离、资源管理和状态检查 checkpointing。每个 OpenVZ 容器都有一套隔离的文件系统、用户及用户组、进程树、网络、设备和 IPC 对象。
这个时期的进程隔离技术大多以 Jail 模式为核心，基本实现了进程相关资源的隔离操作，但由于此时的生产开发仍未有相应的使用场景，这一技术始终被局限在了小众而有限的世界里。
就在此时，一种名为“云”的新技术正悄然萌发……
“云”的诞生
2003 年至 2006 年间，Google 公司陆续发布了 3 篇产品设计论文，从计算方式到存储方式，开创性地提出了分布式计算架构，奠定了大数据计算技术的基础。在此基础上，Google 颠覆性地提出“Google 101”计划，并正式创造“云”的概念。一时间，“云计算”、“云存储”等全新词汇轰动全球。随后，亚马逊、IBM 等行业巨头也陆续宣布各自的“云”计划，宣告“云”技术时代的来临。
也是从这时期开始，进程隔离技术进入了一个更高级的阶段。在 Google 提出的云计算框架下，被隔离的进程不仅仅是一个与外界隔绝但本身却巍然不动的 Jail，它们更需要像一个个轻便的容器，除了能够与外界隔离之外，还要能够被控制与调配，从而实现分布式应用场景下的跨平台、高可用、可扩展等特性。
2006 年 —— Google 推出 Process Containers，后更名为 Cgroups
Process Container 是 Google 工程师眼中“容器”技术的雏形，用来对一组进程进行限制、记账、隔离资源（CPU、内存、磁盘 I/O、网络等）。这与前面提到的进程隔离技术的目标其实是一致的。由于技术更加成熟，Process Container 在 2006 年正式推出后，第二年就进入了 Linux 内核主干，并正式更名为 Cgroups，标志着 Linux 阵营中“容器”的概念开始被重新审视和实现。
2008 年 —— Linux 容器工具 LXC 诞生
在 2008 年，通过将 Cgroups 的资源管理能力和 Linux Namespace（命名空间）的视图隔离能力组合在一起，一项完整的容器技术 LXC（Linux Container）出现在了 Linux 内核中，这就是如今被广泛应用的容器技术的实现基础。我们知道，一个进程可以调用它所在物理机上的所有资源，这样一来就会挤占其它进程的可用资源，为了限制这样的情况，Linux 内核开发者提供了一种特性，进程在一个 Cgroup 中运行的情况与在一个命名空间中类似，但是 Cgroup 可以限制该进程可用的资源。尽管 LXC 提供给用户的能力跟前面提到的各种 Jails 以及 OpenVZ 等早期 Linux 沙箱技术是非常相似的，但伴随着各种 Linux 发行版开始迅速占领商用服务器市场，包括 Google 在内的众多云计算先锋厂商得以充分活用这一早期容器技术，让 LXC 在云计算领域获得了远超前辈的发展空间 。
同年，Google 基于 LXC 推出首款应用托管平台 GAE （Google App Engine），首次把开发平台当做一种服务来提供。GAE 是一种分布式平台服务，Google 通过虚拟化技术为用户提供开发环境、服务器平台、硬件资源等服务，用户可以在平台基础上定制开发自己的应用程序并通过 Google 的服务器和互联网资源进行分发，大大降低了用户自身的硬件要求。
值得一提的是，Google 在 GAE 中使用了一个能够对 LXC 进行编排和调度的工具 —— Borg （Kubernetes 的前身）。Borg 是 Google 内部使用的大规模集群管理系统，可以承载十万级的任务、数千个不同的应用、同时管理数万台机器。Borg 通过权限管理、资源共享、性能隔离等来达到高资源利用率。它能够支持高可用应用，并通过调度策略减少出现故障的概率，提供了任务描述语言、实时任务监控、分析工具等。如果说一个个隔离的容器是集装箱，那么 Borg 可以说是最早的港口系统，而 LXC + Borg 就是最早的容器编排框架。此时，容器已经不再是一种单纯的进程隔离功能，而是一种灵活、轻便的程序封装模式。
2011 年 —— Cloud Foundry 推出 Warden
Cloud Foundry 是知名云服务供应商 VMware 在 2009 年推出的一个云平台，也是业内首个正式定义 PaaS （平台即服务）模式的项目，“PaaS 项目通过对应用的直接管理、编排和调度让开发者专注于业务逻辑而非基础设施”，以及“PaaS 项目通过容器技术来封装和启动应用”等理念都出自 Cloud Foundry。Warden 是 Cloud Foundry 核心部分的资源管理容器，它最开始是一个 LXC 的封装，后来重构成了直接对 Cgroups 以及 Linux Namespace 操作的架构。
随着“云”服务市场的不断开拓，各种 PaaS 项目陆续出现，容器技术也迎来了一个爆发式增长的时代，一大批围绕容器技术进行的创业项目陆续涌现。当然，后来的故事很多人都知道了，一家叫 Docker 的创业公司横空出世，让 Docker 几乎成为了“容器”的代名词。
Docker 横空出世
2013 年 —— Docker 诞生
Docker 最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目，后来该公司改名为 Docker。Docker 在初期与 Warden 类似，使用的也是 LXC ，之后才开始采用自己开发的 libcontainer 来替代 LXC 。与其他只做容器的项目不同的是，Docker 引入了一整套管理容器的生态系统，这包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰的 REST API、命令行等等。
Docker 本身其实也是属于 LXC 的一种封装，提供简单易用的容器使用接口。它最大的特性就是引入了容器镜像。Docker 通过容器镜像，将应用程序与运行该程序需要的环境，打包放在一个文件里面。运行这个文件，就会生成一个虚拟容器。
更为重要的是，Docker 项目还采用了 Git 的思路 —— 在容器镜像的制作上引入了“层”的概念。基于不同的“层”，容器可以加入不同的信息，使其可以进行版本管理、复制、分享、修改，就像管理普通的代码一样。通过制作 Docker 镜像，开发者可以通过 DockerHub 这样的镜像托管仓库，把软件直接进行分发。
也就是说，Docker 的诞生不仅解决了软件开发层面的容器化问题，还一并解决了软件分发环节的问题，为“云”时代的软件生命周期流程提供了一套完整的解决方案。
很快，Docker 在业内名声大噪，被很多公司选为云计算基础设施建设的标准，容器化技术也成为业内最炙手可热的前沿技术，围绕容器的生态建设风风火火地开始了。
容器江湖之争
一项新技术的兴起同时也带来了一片新的市场，一场关于容器的蓝海之争也在所难免。
2013 年 —— CoreOS 发布
在 Docker 爆火后，同年年末，CoreOS 应运而生。CoreOS 是一个基于 Linux 内核的轻量级操作系统，专为云计算时代计算机集群的基础设施建设而设计，拥有自动化、易部署、安全可靠、规模化等特性。其在当时有一个非常显眼的标签：专为容器设计的操作系统。
借着 Docker 的东风，CoreOS 迅速在云计算领域蹿红，一时间，Docker + CoreOS 成为业内容器部署的黄金搭档。同时，CoreOS 也为 Docker 的推广与社区建设做出了巨大的贡献。
然而，日渐壮大的 Docker 似乎有着更大的“野心”。不甘于只做“一种简单的基础单元”的 Docker，自行开发了一系列相关的容器组件，同时收购了一些容器化技术的公司，开始打造属于自己的容器生态平台。显然，这对于 CoreOS 来说形成了直接的竞争关系。
2014 年 —— CoreOS 发布开源容器引擎 Rocket
2014 年末，CoreOS 推出了自己的容器引擎 Rocket （简称 rkt），试图与 Docker 分庭抗礼。rkt 和 Docker 类似，都能帮助开发者打包应用和依赖包到可移植容器中，简化搭环境等部署工作。rkt 和 Docker 不同的地方在于，rkt 没有 Docker 那些为企业用户提供的“友好功能”，比如云服务加速工具、集群系统等。反过来说，rkt 想做的，是一个更纯粹的业界标准。
2014 年 —— Google 推出开源的容器编排引擎 Kubernetes
为了适应混合云场景下大规模集群的容器部署、管理等问题，Google 在 2014 年 6 月推出了容器集群管理系统 Kubernetes （简称 K8S）。K8S 来源于我们前面提到的 Borg，拥有在混合云场景的生产环境下对容器进行管理、编排的功能。Kubernetes 在容器的基础上引入了 Pod 功能，这个功能可以让不同容器之间互相通信，实现容器的分组调配。
得益于 Google 在大规模集群基础设施建设的强大积累，脱胎于 Borg 的 K8S 很快成为了行业的标准应用，堪称容器编排的必备工具。而作为容器生态圈举足轻重的一员，Google 在 Docker 与 rkt 的容器之争中站在了 CoreOS 一边，并将 K8S 支持 rkt 作为一个重要里程碑。
2015 年 —— Docker 推出容器集群管理工具 Docker Swarm
作为回应，Docker 公司在 2015 年发布的 Docker 1.12 版本中也开始加入了一个容器集群管理工具 Docker swarm 。
随后，Google 于 2015 年 4 月领投 CoreOS 1200 万美元， 并与 CoreOS 合作发布了首个企业发行版的 Kubernetes —— Tectonic 。从此，容器江湖分为两大阵营，Google 派系和 Docker 派系。
两大派系的竞争愈演愈烈，逐渐延伸到行业标准的建立之争。
2015 年 6 月 —— Docker 带头成立 OCI
Docker 联合 Linux 基金会成立 OCI （Open Container Initiative）组织，旨在“制定并维护容器镜像格式和容器运行时的正式规范（“OCI Specifications”），围绕容器格式和运行时制定一个开放的工业化标准。
2015 年 7 月 —— Google 带头成立 CNCF
而战略目标聚焦于“云”的 Google 在同年 7 月也联合 Linux 基金会成立 CNCF （Cloud Native Computing Foundation）云原生计算基金会，并将 Kubernetes 作为首个编入 CNCF 管理体系的开源项目，旨在“构建云原生计算 —— 一种围绕着微服务、容器和应用动态调度的、以基础设施为中心的架构，并促进其广泛使用”。
这两大围绕容器相关开源项目建立的开源基金会为推动日后的云原生发展发挥了重要的作用，二者相辅相成，制定了一系列行业事实标准，成为当下最为活跃的开源组织。
Kubernetes 生态一统江湖
虽然这些年来 Docker 一直力压 rkt，成为当之无愧的容器一哥，但作为一个庞大的容器技术生态来说，Docker 生态还是在后来的容器编排之争中败给了 Google 的 Kubernetes 。
随着越来越多的开发者使用 Docker 来部署容器，编排平台的重要性日益突出。在 Docker 流行之后，一大批开源项目和专有平台陆续出现，以解决容器编排的问题。Mesos、Docker Swarm 和 Kubernetes 等均提供了不同的抽象来管理容器。这一时期，对于软件开发者来说，选择容器编排平台就像是一场豪赌，因为一旦选择的平台在以后的竞争中败下阵来，就意味着接下来开发的东西在未来将失去市场。就像当初 Android、iOS 和 WP 的手机系统之争一样，只有胜利者才能获得更大的市场前景，失败者甚至会销声匿迹。容器编排平台之争就此拉开帷幕。
2016 年 —— CRI-O 诞生
2016 年，Kubernetes 项目推出了 CRI （容器运行时接口），这个插件接口让 kubelet（一种用来创建 pod、启动容器的集群节点代理）能够使用不同的、符合 OCI 的容器运行时环境，而不需要重新编译 Kubernetes。基于 CRI ，一个名为 CRI-O 的开源项目诞生，旨在为 Kubernetes 提供一种轻量级运行时环境。
CRI-O 可以让开发者直接从 Kubernetes 来运行容器，这意味着 Kubernetes 可以不依赖于传统的容器引擎（比如 Docker ），也能够管理容器化工作负载。这样一来，在 Kubernetes 平台上，只要容器符合 OCI 标准（不一定得是 Docker），CRI-O 就可以运行它，让容器回归其最基本的功能 —— 能够封装并运行云原生程序即可。
同时，CRI-O 的出现让使用容器技术进行软件管理和运维的人们发现，相对于 Docker 本身的标准容器引擎， Kubernetes 技术栈（比如编排系统、 CRI 和 CRI-O ）更适合用来管理复杂的生产环境。可以说，CRI-O 将容器编排工具放在了容器技术栈的重要位置，从而降低了容器引擎的重要性。
在 K8S 顺利抢占先机的情况下，Docker 在推广自己的容器编排平台 Docker Swarm 时反而犯下了错误。2016 年底，业内曝出 Docker 为了更好地适配 Swarm，将有可能改变 Docker 标准的传言。这让许多开发者在平台的选择上更倾向于与市场兼容性更强的 Kubernetes 。
因此，在进入 2017 年之后，更多的厂商愿意把宝压在 K8S 上，投入到 K8S 相关生态的建设中来。容器编排之争以 Google 阵营的胜利告一段落。与此同时，以 K8S 为核心的 CNCF 也开始迅猛发展，成为当下最火的开源项目基金会。这两年包括阿里云、腾讯、百度等中国科技企业也陆续加入 CNCF ，全面拥抱容器技术与云原生。
结语
从数十年前在实验室里对进程隔离功能的探索，再到如今遍布生产环境的云原生基础设施建设，可以说容器技术凝聚了几代开发者的心血，才从一个小小的集装箱发展到一个大型的现代化港口。可以预见的是，从现在到未来很长一段时间里，容器技术都将是软件开发和运维的重要基础设施。
说一说什么是虚拟化？
随着虚拟化、云计算等技术的兴起，IT界将具有几十年历史的虚拟化技术再一次赋予了新的内涵，虚拟化的外延也得到了扩展。然而，到目前为止，虚拟化还没有一个公认的、标准的定义，人们大多借用虚拟化的用途给出了不同的说法，总体来说，虚拟化的定义都可以概括和表述为：物理资源的逻辑抽象实现。
虚拟化定义
针对快速发展的虚拟化技术，世界一些标准化组织和大公司都给出了各自的虚拟化的定义，下面摘录一些定义：
IBM公司的定义是：“虚拟化是资源的逻辑表示，它不受物理限制的约束。”
维基百科（Wikipedia）的定义是：“虚拟化是表示计算机资源的逻辑组（或子集）的过程，这样就可以用从原始配置中获益的方式访问它们。这种资源的新虚拟视图并不受实现、地理位置或底层资源的物理配置的限制。”
Jonathan Eunice，llluminatalne 的定义是：“虚拟化是以某种用户和应用程序都可以很容易从中获益的方式来表示计算机资源的过程，而不是根据这些资源的实现、地理位置或物理包装的专有方式来表示它们。换句话说，它为数据、计算能力、存储资源以及其他资源提供了一个逻辑视图，而不是物理视图。”
linux虚拟化什么意思
虚拟化技术的应用十分广泛. 当前虚拟化技术主要关注于服务器的虚拟化, 或在单个主机上寄存多个独立的操作系统. 本文首先介绍虚拟化技术的原理, 然后讨论多个虚拟化技术的实现方法. 另外介绍了一些其它的虚拟化技术, 比如Linux上操作系统级的虚拟化技术.
虚拟化把事物从一种形式改变为另一种形式. 计算机的虚拟化使单个计算机看起来像多个计算机或完全不同的计算机.
虚拟化技术也可以使多台计算机看起来像一台计算机. 这叫做服务器聚合(server aggregation)或网格计算(grid computing).
首先我们回顾一下虚拟化技术的历史.
虚拟化技术的历史
虚拟化技术不是一个新的主题; 实际上, 它已有40年的历史. 最早使用虚拟化技术的是IBM 7044计算机, 它是基于MIT(麻省理工学院)为IBM704计算机开发的分时系统CTSS(Compatible Time Sharing System), 和曼彻斯特大学的Atlas项目(世界最早的超级计算机之一), 首次使用了请求调页和系统管理程序调用.
硬件虚拟化
IBM早在1960年就认识到虚拟化技术的重要性, 于是开发了型号为Model 67的System/360主机. Model 67主机通过虚拟机监视器(VMM, Virtual Machine Monitor)虚拟所有的硬件接口. 在早期的计算中, 操作系统被称做Supervisor. 能够运行在其它操作系统之上的操作系统被称做hypervisor(名称首次出现在1970年).
VMM直接运行在底层硬件上, 允许执行多个虚拟机(VMs). 每一个VM(虚拟机)运行自己的操作系统实例 -- 早期时候称为CMS, 或会话监视系统(CMS, Conversational Monitor System). 然后VM继续发展. 今天你能够在System z9主机上发现VM, 它能够向后兼容, 甚至是System/360.
处理器虚拟化
另外一个早期使 用的虚拟化技术, 仿真处理器, 也叫做P-code(or pseudo-code)机. P-code是一种机器语言, 运行在虚拟机上而不是实际的硬件. 知名的P-code语言在1970年由加州大学圣地亚哥分校的Pascal系统项目组开发. 它可以把Pascal程序编译成P-code代码, 然后在具有P-code功能的虚拟机上运行. P-code程序具有高度可移植性, 能够运行在任何具有P-code功能的虚拟机上.
1960年的BCPL语言(基本组合程序设计语言, Basic Combined Programming Language)也使用了同样的概念, 它是C语言的前身. 编译器首先把BCPL代码编译成一个中间机器代码: O-code. 然后, O-code被编译成目标机器代码. P-code模型已被广泛使用到各种编译器当中, 从而为编译器移植到新的主机架构提供了复杂性.(通过一个中间语言分成前端和后端).
Java虚拟机(JVM)
Java虚拟机也采用了P-code模型. 从而我们可以简单通过移植JVM程序到新架构的机器上来广泛发布Java程序.
指令虚拟化
近来频繁出现的虚拟化概念: 指令虚拟化, 也叫做二进制翻译. 在这个模型中, 虚拟指令被动态翻译成底层硬件的物理指令. 程序执行后, 代码一段一段地被翻译. 如果出现分支, 一套新的代码指令将被引入和翻译. 这十分类似于缓存操作, 指令块从内存移动到本地的快速缓存内存中执行.
近来Transmeta公司设计的Crusoe中央处理器使用了该模型. 二进制翻译由Code Morphing专利技术实现. 类似的一个实例, 全虚拟技术通过使用动态生成代码扫描来发现和重定向特权指令(解决特殊处理指令集中的问题).
虚拟化技术的类型
现在不只存在一种虚拟化技术. 事实上有多种方法可以使用不同层次的抽象来实现同样的结果. 本章介绍Linux上三种最常用虚拟化技术的优点和弱点. 业届有时使用不同的术语来描述同一个虚拟化技术. 为了保持连续性, 下面使用的术语参考了其它的术语.
虚拟化技术和游戏
一篇虚拟化技术的文章如果没有提到复合式大型电玩模拟器(MAME)就不是一篇完整的文章. MAME, 就如名字一样, 是一个能够模拟以往arcade游戏的机器模拟器(全部). 做一个补充, 整个机器是被虚拟的, 包括声音和图形还有控制硬件. MAME是一个非常棒的应用程序, 你也可以通过仔细阅读源码来了解它是如何实现的.
硬件模拟器
无可否认, 最复杂的虚拟化技术是硬件模拟器. 在这个方法中, 首先在主机系统上创建硬件VM, 然后模拟硬件的功能, 如图1显示:
图1. 硬件模拟器: 使用VM模拟需要的硬件
正如你可能猜到, 硬件模拟器的主要问题是速度极慢. 因为每一个指令在底层硬件都需模拟, 所以速度慢了100倍. 高保真模拟还包含了循环校验, 用于模拟CPU的管道和缓存行为, 实际速度会慢了1000倍.
硬件模拟有自己的优点. 比如, 使用硬件模拟, 你能够在基于ARM处理器的主机上模拟运行基于PowerPC未经任何修改的操作系统. 你甚至能在每个不同模拟处理器上运行多个虚拟机.
模拟器和开发
硬件模拟器最有意思的一个应用是firmware(固件)和硬件协作开发. firmware开发人员无需等待最新硬件的推出, 他们可以使用目标硬件的虚拟机来验证实际代码中的许多概念.
全虚拟化
全虚拟化(Full virtualization), 也称为原始虚拟化技术, 是另一种虚拟化方法. 该模型使用虚拟机协调客户操作系统和原始硬件(见图2). 这里"协调"是一个关键词, 因为VMM在客户操作系统和裸硬件之间用于工作协调. 一些受保护的指令必须由Hypervisor(虚拟机管理程序)来捕获和处理. 因为操作系统是通过Hypervisor来分享底层硬件.
图2. 全虚拟化: 使用Hypervisor分享底层硬件
全虚拟化的运行速度要快于硬件模拟, 但是性能方面不如裸机, 因为Hypervisor需要占用一些资源. 全虚拟化最大的优点是操作系统没有经过任何修改. 它的唯一限制是操作系统必须能够支持底层硬件(比如, PowerPC).
老机器上的Hypervisors
一些老的硬件如x86, 全虚拟化遇到了问题. 比如, 一些敏感的指令需要由VMM来处理(VMM不能设置陷阱). 因此, Hypervisors必须动态扫描和捕获特权代码来处理问题.
半虚拟化
半虚拟化(Paravirtualization)是另一种类似于全虚拟化的热门技术. 它使用Hypervisor(虚拟机管理程序)分享存取底层的硬件, 但是它的客户操作系统集成了虚拟化方面的代码. 该方法无需重新编译或引起陷阱, 因为操作系统自身能够与虚拟进程进行很好的协作.
图3. 半虚拟化: 通过客户操作系统分享进程
上面提到过, 半虚拟化需要客户操作系统做一些修改(配合Hypervisor), 这是一个不足之处. 但是半虚拟化提供了与原始系统相近的性能. 与全虚拟化一样, 半虚拟化可以同时能支持多个不同的操作系统.
操作系统级的虚拟化
最后一个我们需要了解的虚拟化技术是操作系统级的虚拟化(Operating system-level virtualization), 它使用不同于上面的虚拟化方法. 该技术在操作系统之上虚拟多个服务器, 支持在单个操作系统上简单隔离每一个虚拟服务器(见图4).
图4. 操作系统级的虚拟化: 隔离单个服务器
操作系统级的虚拟化需要修改操作系统内核, 它的优点是具有原始主机的性能.
为什么虚拟技术如此重要?
在了解当今主流的linux虚拟化技术之前, 我们先来看虚拟化技术的优点.
从商业角度来看, 使用虚拟化技术有非常多的原因. 不过大多是用于服务器加固. 简单来说, 如果你能够在单个服务上虚拟多个系统, 这样少数的几台计算机显然能够节省耗电, 空间, 冷却和管理开支. 考虑到确定服务器利用状况的困难, 虚拟化技术支持动态迁移(Live Migration). 动态迁移允许操作系统能够迁移到另一台全新的服务器上, 从而减少当前主机的负载.
虚拟化技术对开发人员来说 也非常重要. Linux内核占用了一个单一的地址空间, 这意味内核或任何驱动程序错误都能导致整个操作系统停止工作. 而通过虚拟化你可以运行多个操作系统, 如果其中一个系统由于错误而宕机, Hypervisor和其它的操作系统不会受到任何影响. 这对调试内核来说就如同调试用户空间程序一样.
采用桌面虚拟化办公有什么样的弊病？
1. 基于VDI 模式的桌面虚拟化对服务器的消耗非常高，特别是客户机提交上来的运算量大时，对网络的压力也相当大，如果几十台客户机同时登录连接虚拟桌面时，可能会产生风暴，造成短时间的卡机。
2. 用户权限的管理依赖于WINDOWS 域用户管理策略，必须有域服务器作为支撑。
3. 在基于VDI的虚拟桌面上进行图形处理或三维、高清等工作时，会表现出极不流畅的反映，花屏、重影等情况比较严重。
不过，你们实际应用中如果舍得在服务器硬件和网络建设上投入大量的资金，上述问题可以得到缓解。
虚拟化技术都包含什么内容？
虚拟化技术简介
什么是虚拟化
虚拟化（Virtualization）技术最早出现在 20 世纪 60 年代的 IBM 大型机系统，在70年代的 System 370 系列中逐渐流行起来，这些机器通过一种叫虚拟机监控器（Virtual Machine Monitor，VMM）的程序在物理硬件之上生成许多可以运行独立操作系统软件的虚拟机（Virtual Machine）实例。随着近年多核系统、集群、网格甚至云计算的广泛部署，虚拟化技术在商业应用上的优势日益体现，不仅降低了 IT 成本，而且还增强了系统安全性和可靠性，虚拟化的概念也逐渐深入到人们日常的工作与生活中。
虚拟化是一个广义的术语，对于不同的人来说可能意味着不同的东西，这要取决他们所处的环境。在计算机科学领域中，虚拟化代表着对计算资源的抽象，而不仅仅局限于虚拟机的概念。例如对物理内存的抽象，产生了虚拟内存技术，使得应用程序认为其自身拥有连续可用的地址空间（Address Space），而实际上，应用程序的代码和数据可能是被分隔成多个碎片页或段），甚至被交换到磁盘、闪存等外部存储器上，即使物理内存不足，应用程序也能顺利执行。
虚拟化技术的分类
虚拟化技术主要分为以下几个大类 [1]：
平台虚拟化（Platform Virtualization），针对计算机和操作系统的虚拟化。
资源虚拟化（Resource Virtualization），针对特定的系统资源的虚拟化，比如内存、存储、网络资源等。
应用程序虚拟化（Application Virtualization），包括仿真、模拟、解释技术等。
我们通常所说的虚拟化主要是指平台虚拟化技术，通过使用控制程序（Control Program，也被称为 Virtual Machine Monitor 或 Hypervisor），隐藏特定计算平台的实际物理特性，为用户提供抽象的、统一的、模拟的计算环境（称为虚拟机）。虚拟机中运行的操作系统被称为客户机操作系统（Guest OS），运行虚拟机监控器的操作系统被称为主机操作系统（Host OS），当然某些虚拟机监控器可以脱离操作系统直接运行在硬件之上（如 VMWARE 的 ESX 产品）。运行虚拟机的真实系统我们称之为主机系统。
平台虚拟化技术又可以细分为如下几个子类：
全虚拟化（Full Virtualization）
全虚拟化是指虚拟机模拟了完整的底层硬件，包括处理器、物理内存、时钟、外设等，使得为原始硬件设计的操作系统或其它系统软件完全不做任何修改就可以在虚拟机中运行。操作系统与真实硬件之间的交互可以看成是通过一个预先规定的硬件接口进行的。全虚拟化 VMM 以完整模拟硬件的方式提供全部接口（同时还必须模拟特权指令的执行过程）。举例而言，x86 体系结构中，对于操作系统切换进程页表的操作，真实硬件通过提供一个特权 CR3 寄存器来实现该接口，操作系统只需执行 "mov pgtable,%%cr3" 汇编指令即可。全虚拟化 VMM 必须完整地模拟该接口执行的全过程。如果硬件不提供虚拟化的特殊支持，那么这个模拟过程将会十分复杂：一般而言，VMM 必须运行在最高优先级来完全控制主机系统，而 Guest OS 需要降级运行，从而不能执行特权操作。当 Guest OS 执行前面的特权汇编指令时，主机系统产生异常（General Protection Exception），执行控制权重新从 Guest OS 转到 VMM 手中。VMM 事先分配一个变量作为影子 CR3 寄存器给 Guest OS，将 pgtable 代表的客户机物理地址（Guest Physical Address）填入影子 CR3 寄存器，然后 VMM 还需要 pgtable 翻译成主机物理地址（Host Physical Address）并填入物理 CR3 寄存器，最后返回到 Guest OS中。随后 VMM 还将处理复杂的 Guest OS 缺页异常（Page Fault）。比较著名的全虚拟化 VMM 有 Microsoft Virtual PC、VMware Workstation、Sun Virtual Box、Parallels Desktop for Mac 和 QEMU。
超虚拟化（Paravirtualization）
这是一种修改 Guest OS 部分访问特权状态的代码以便直接与 VMM 交互的技术。在超虚拟化虚拟机中，部分硬件接口以软件的形式提供给客户机操作系统，这可以通过 Hypercall（VMM 提供给 Guest OS 的直接调用，与系统调用类似）的方式来提供。例如，Guest OS 把切换页表的代码修改为调用 Hypercall 来直接完成修改影子 CR3 寄存器和翻译地址的工作。由于不需要产生额外的异常和模拟部分硬件执行流程，超虚拟化可以大幅度提高性能，比较著名的 VMM 有 Denali、Xen。
硬件辅助虚拟化（Hardware-Assisted Virtualization）
硬件辅助虚拟化是指借助硬件（主要是主机处理器）的支持来实现高效的全虚拟化。例如有了 Intel-VT 技术的支持，Guest OS 和 VMM 的执行环境自动地完全隔离开来，Guest OS 有自己的“全套寄存器”，可以直接运行在最高级别。因此在上面的例子中，Guest OS 能够执行修改页表的汇编指令。Intel-VT 和 AMD-V 是目前 x86 体系结构上可用的两种硬件辅助虚拟化技术。
部分虚拟化（Partial Virtualization）
VMM 只模拟部分底层硬件，因此客户机操作系统不做修改是无法在虚拟机中运行的，其它程序可能也需要进行修改。在历史上，部分虚拟化是通往全虚拟化道路上的重要里程碑，最早出现在第一代的分时系统 CTSS 和 IBM M44/44X 实验性的分页系统中。
操作系统级虚拟化（Operating System Level Virtualization）
在传统操作系统中，所有用户的进程本质上是在同一个操作系统的实例中运行，因此内核或应用程序的缺陷可能影响到其它进程。操作系统级虚拟化是一种在服务器操作系统中使用的轻量级的虚拟化技术，内核通过创建多个虚拟的操作系统实例（内核和库）来隔离不同的进程，不同实例中的进程完全不了解对方的存在。比较著名的有 Solaris Container [2]，FreeBSD Jail 和 OpenVZ 等。
这种分类并不是绝对的，一个优秀的虚拟化软件往往融合了多项技术。例如 VMware Workstation 是一个著名的全虚拟化的 VMM，但是它使用了一种被称为动态二进制翻译的技术把对特权状态的访问转换成对影子状态的操作，从而避免了低效的 Trap-And-Emulate 的处理方式，这与超虚拟化相似，只不过超虚拟化是静态地修改程序代码。对于超虚拟化而言，如果能利用硬件特性，那么虚拟机的管理将会大大简化，同时还能保持较高的性能。
本文讨论的虚拟化技术只针对 x86 平台（含 AMD 64），并假定虚拟机中运行的 Guest OS 也是为 x86 平台设计的。
--------------------------------------------------------------------------------
回页首
纯软件虚拟化技术的原理及面临的挑战
虚拟机监控器应当具备的条件
1974 年，Popek 和 Goldberg 在《Formal Requirements for Virtualizable Third Generation Architectures》[3] 论文中提出了一组称为虚拟化准则的充分条件，满足这些条件的控制程序可以被称为虚拟机监控器（Virtual Machine Monitor，简称 VMM）：
资源控制。控制程序必须能够管理所有的系统资源。
等价性。在控制程序管理下运行的程序（包括操作系统），除时序和资源可用性之外的行为应该与没有控制程序时的完全一致，且预先编写的特权指令可以自由地执行。
效率性。绝大多数的客户机指令应该由主机硬件直接执行而无需控制程序的参与。
尽管基于简化的假设，但上述条件仍为评判一个计算机体系结构是否能够有效支持虚拟化提供了一个便利方法，也为设计可虚拟化计算机架构给出了指导原则。
原理简介
我们知道，传统的 x86 体系结构缺乏必要的硬件支持，任何虚拟机监控器都无法直接满足上述条件，所以不是一个可虚拟化架构，但是我们可以使用纯软件实现的方式构造虚拟机监控器。
虚拟机是对真实计算环境的抽象和模拟，VMM 需要为每个虚拟机分配一套数据结构来管理它们状态，包括虚拟处理器的全套寄存器，物理内存的使用情况，虚拟设备的状态等等。VMM 调度虚拟机时，将其部分状态恢复到主机系统中。并非所有的状态都需要恢复，例如主机 CR3 寄存器中存放的是 VMM 设置的页表物理地址，而不是 Guest OS 设置的值。主机处理器直接运行 Guest OS 的机器指令，由于 Guest OS运行在低特权级别，当访问主机系统的特权状态（如写 GDT 寄存器）时，权限不足导致主机处理器产生异常，将运行权自动交还给 VMM。此外，外部中断的到来也会导致 VMM 的运行。VMM 可能需要先将 该虚拟机的当前状态写回到状态数据结构中，分析虚拟机被挂起的原因，然后代表 Guest OS 执行相应的特权操作。最简单的情况，如Guest OS 对 CR3 寄存器的修改，只需要更新虚拟机的状态数据结构即可。一般而言，大部分情况下，VMM 需要经过复杂的流程才能完成原本简单的操作。最后 VMM 将运行权还给 Guest OS，Guest OS 从上次被中断的地方继续执行，或处理 VMM “塞”入的虚拟中断和异常。这种经典的虚拟机运行方式被称为 Trap-And-Emulate，虚拟机对于 Guest OS 完全透明，Guest OS 不需要任何修改，但是 VMM 的设计会比较复杂，系统整体性能受到明显的损害。
面临的挑战
在设计纯软件 VMM 的时候，需要解决如下挑战 [4]：
确保 VMM 控制所有的系统资源。
x86 处理器有 4 个特权级别，Ring 0 ~ Ring 3，只有运行在 Ring 0 ~ 2 级时，处理器才可以访问特权资源或执行特权指令；运行在 Ring 0 级时，处理器可以访问所有的特权状态。x86 平台上的操作系统一般只使用 Ring 0 和 Ring 3 这两个级别，操作系统运行在 Ring 0 级，用户进程运行在 Ring 3 级。为了满足上面的第一个充分条件-资源控制，VMM 自己必须运行在 Ring 0 级，同时为了避免 Guest OS 控制系统资源，Guest OS 不得不降低自身的运行级别，运行在 Ring 1 或 Ring 3 级（Ring 2 不使用）。
特权级压缩（Ring Compression）。
VMM 使用分页或段限制的方式保护物理内存的访问，但是 64 位模式下段限制不起作用，而分页又不区分 Ring 0, 1, 2。为了统一和简化 VMM的设计，Guest OS 只能和 Guest 进程一样运行在 Ring 3 级。VMM 必须监视 Guest OS 对 GDT、IDT 等特权资源的设置，防止 Guest OS 运行在 Ring 0级，同时又要保护降级后的 Guest OS 不受 Guest 进程的主动攻击或无意破坏。
特权级别名（Ring Alias）。
特权级别名是指 Guest OS 在虚拟机中运行的级别并不是它所期望的。VMM 必须保证 Guest OS 不能获知正在虚拟机中运行这一事实，否则可能打破等价性条件。例如，x86 处理器的特权级别存放在 CS 代码段寄存器内，Guest OS 可以使用非特权 push 指令将 CS 寄存器压栈，然后 pop 出来检查该值。又如，Guest OS 在低特权级别时读取特权寄存器 GDT、LDT、IDT 和 TR，并不发生异常，从而可能发现这些值与自己期望的不一样。为了解决这个挑战，VMM 可以使用动态二进制翻译的技术，例如预先把 “push %%cs” 指令替换，在栈上存放一个影子 CS 寄存器值；又如，可以把读取 GDT 寄存器的操作“sgdt dest”改为“movl fake_gdt, dest”。
地址空间压缩（Address Space Compression）。
地址空间压缩是指 VMM 必须在Guest OS 的地址空间中保留一部分供其使用。例如，中断描述表寄存器（IDT Register）中存放的是中断描述表的线性地址，如果 Guest OS 运行过程中来了外部中断或触发处理器异常，必须保证运行权马上转移到 VMM 中，因此 VMM 需要将 Guest OS 的一部分线性地址空间映射成自己的中断描述表的主机物理地址。VMM 可以完全运行在 Guest OS 的地址空间中，也可以拥有独立的地址空间，后者的话，VMM 只占用 Guest OS 很少的地址空间，用于存放中断描述表和全局描述符表（GDT）等重要的特权状态。无论如何哪种情况，VMM 应该防止 Guest OS 直接读取和修改这部分地址空间。
处理 Guest OS 的缺页异常。
内存是一种非常重要的系统资源，VMM 必须全权管理，Guest OS 理解的物理地址只是客户机物理地址（Guest Physical Address），并不是最终的主机物理地址（Host Physical Address）。当 Guest OS 发生缺页异常时，VMM 需要知道缺页异常的原因，是 Guest 进程试图访问没有权限的地址，或是客户机线性地址（Guest Linear Address）尚未翻译成 Guest Physical Address，还是客户机物理地址尚未翻译成主机物理地址。一种可行的解决方法是 VMM 为 Guest OS 的每个进程的页表构造一个影子页表，维护 Guest Linear Address 到 Host Physical Address 的映射，主机 CR3 寄存器存放这个影子页表的物理内存地址。VMM 同时维护一个 Guest OS 全局的 Guest Physical Address 到 Host Physical Address 的映射表。发生缺页异常的地址总是Guest Linear Address，VMM 先去 Guest OS 中的页表检查原因，如果页表项已经建立，即对应的Guest Physical Address 存在，说明尚未建立到 Host Physical Address的映射，那么 VMM 分配一页物理内存，将影子页表和映射表更新；否则，VMM 返回到 Guest OS，由 Guest OS 自己处理该异常。
处理 Guest OS 中的系统调用。
系统调用是操作系统提供给用户的服务例程，使用非常频繁。最新的操作系统一般使用 SYSENTER/SYSEXIT 指令对来实现快速系统调用。SYSENTER 指令通过IA32_SYSENTER_CS，IA32_SYSENTER_EIP 和 IA32_SYSENTER_ESP 这 3 个 MSR（Model Specific Register）寄存器直接转到 Ring 0级；而 SYSEXIT 指令不在 Ring 0 级执行的话将触发异常。因此，如果 VMM 只能采取 Trap-And-Emulate 的方式处理这 2 条指令的话，整体性能将会受到极大损害。
转发虚拟的中断和异常。
所有的外部中断和主机处理器的异常直接由 VMM 接管，VMM 构造必需的虚拟中断和异常，然后转发给 Guest OS。VMM 需要模拟硬件和操作系统对中断和异常的完整处理流程，例如 VMM 先要在 Guest OS 当前的内核栈上压入一些信息，然后找到 Guest OS 相应处理例程的地址，并跳转过去。VMM 必须对不同的 Guest OS 的内部工作流程比较清楚，这增加了 VMM 的实现难度。同时，Guest OS 可能频繁地屏蔽中断和启用中断，这两个操作访问特权寄存器 EFLAGS，必须由 VMM 模拟完成，性能因此会受到损害。 Guest OS 重新启用中断时，VMM 需要及时地获知这一情况，并将积累的虚拟中断转发。
Guest OS 频繁访问特权资源。
Guest OS对特权资源的每次访问都会触发处理器异常，然后由 VMM 模拟执行，如果访问过于频繁，则系统整体性能将会受到极大损害。比如对中断的屏蔽和启用，cli（Clear Interrupts）指令在 Pentium 4 处理器上需要花费 60 个时钟周期（cycle）。又如，处理器本地高级可编程中断处理器（Local APIC）上有一个操作系统可修改的任务优先级寄存器（Task-Priority Register），IO-APIC 将外部中断转发到 TPR 值最低的处理器上（期望该处理器正在执行低优先级的线程），从而优化中断的处理。TPR 是一个特权寄存器，某些操作系统会频繁设置（Linux Kernel只在初始化阶段为每个处理器的 TPR 设置相同的值）。
软件 VMM 所遇到的以上挑战从本质上来说是因为 Guest OS 无法运行在它所期望的最高特权级，传统的 Trap-And-Emulate 处理方式虽然以透明的方式基本解决上述挑战，但是带来极大的设计复杂性和性能下降。当前比较先进的虚拟化软件结合使用二进制翻译和超虚拟化的技术，核心思想是动态或静态地改变 Guest OS 对特权状态访问的操作，尽量减少产生不必要的硬件异常，同时简化 VMM 的设计。
--------------------------------------------------------------------------------
回页首
Intel-VT 硬件辅助虚拟化技术详解
2005 年冬天，英特尔带来了业内首个面向台式机的硬件辅助虚拟化技术 Intel-VT 及相关的处理器产品，从而拉开了 IA 架构虚拟化技术应用的新时代大幕。支持虚拟化技术的处理器带有特别优化过的指令集来自动控制虚拟化过程，从而极大简化 VMM 的设计，VMM 的性能也能得到很大提高。其中 IA-32 处理器的虚拟化技术称为 VT-x，安腾处理器的虚拟化技术称为 VT-i。AMD 公司也推出了自己的虚拟化解决方案，称为 AMD-V。尽管 Intel-VT 和 AMD-V 并不完全相同，但是基本思想和数据结构却是相似的，本文只讨论 Intel-VT-x 技术。
新增的两种操作模式
VT-x 为 IA 32 处理器增加了两种操作模式：VMX root operation 和 VMX non-root operation。VMM 自己运行在 VMX root operation 模式，VMX non-root operation 模式则由 Guest OS 使用。两种操作模式都支持 Ring 0 ~ Ring 3 这 4 个特权级，因此 VMM 和 Guest OS 都可以自由选择它们所期望的运行级别。
这两种操作模式可以互相转换。运行在 VMX root operation 模式下的 VMM 通过显式调用 VMLAUNCH 或 VMRESUME 指令切换到 VMX non-root operation 模式，硬件自动加载 Guest OS的上下文，于是 Guest OS 获得运行，这种转换称为 VM entry。Guest OS 运行过程中遇到需要 VMM 处理的事件，例如外部中断或缺页异常，或者主动调用 VMCALL 指令调用 VMM 的服务的时候（与系统调用类似），硬件自动挂起 Guest OS，切换到 VMX root operation 模式，恢复 VMM 的运行，这种转换称为 VM exit。VMX root operation 模式下软件的行为与在没有 VT-x 技术的处理器上的行为基本一致；而VMX non-root operation 模式则有很大不同，最主要的区别是此时运行某些指令或遇到某些事件时，发生 VM exit。
虚拟机控制块
VMM 和 Guest OS 共享底层的处理器资源，因此硬件需要一个物理内存区域来自动保存或恢复彼此执行的上下文。这个区域称为虚拟机控制块（VMCS），包括客户机状态区（Guest State Area），主机状态区（Host State Area）和执行控制区。VM entry 时，硬件自动从客户机状态区加载 Guest OS 的上下文。并不需要保存 VMM 的上下文，原因与中断处理程序类似，因为 VMM 如果开始运行，就不会受到 Guest OS的干扰，只有 VMM 将工作彻底处理完毕才可能自行切换到 Guest OS。而 VMM 的下次运行必然是处理一个新的事件，因此每次 VMM entry 时， VMM 都从一个通用事件处理函数开始执行；VM exit 时，硬件自动将 Guest OS 的上下文保存在客户机状态区，从主机状态区中加载 VMM 的通用事件处理函数的地址，VMM 开始执行。而执行控制区存放的则是可以操控 VM entry 和 exit 的标志位，例如标记哪些事件可以导致 VM exit，VM entry 时准备自动给 Guest OS “塞”入哪种中断等等。
客户机状态区和主机状态区都应该包含部分物理寄存器的信息，例如控制寄存器 CR0，CR3，CR4；ESP 和 EIP（如果处理器支持 64 位扩展，则为 RSP，RIP）；CS，SS，DS，ES，FS，GS 等段寄存器及其描述项；TR，GDTR，IDTR 寄存器；IA32_SYSENTER_CS，IA32_SYSENTER_ESP，IA32_SYSENTER_EIP 和 IA32_PERF_GLOBAL_CTRL 等 MSR 寄存器。客户机状态区并不包括通用寄存器的内容，VMM 自行决定是否在 VM exit 的时候保存它们，从而提高了系统性能。客户机状态区还包括非物理寄存器的内容，比如一个 32 位的 Active State 值表明 Guest OS 执行时处理器所处的活跃状态，如果正常执行指令就是处于 Active 状态，如果触发了三重故障（Triple Fault）或其它严重错误就处于 Shutdown 状态，等等。
前文已经提过，执行控制区用于存放可以操控 VM entry 和 VM exit 的标志位，包括：
External-interrupt exiting：用于设置是否外部中断可以触发 VM exit，而不论 Guest OS 是否屏蔽了中断。
Interrupt-window exiting：如果设置，当 Guest OS 解除中断屏蔽时，触发 VM exit。
Use TPR shadow：通过 CR8 访问 Task Priority Register（TPR）的时候，使用 VMCS 中的影子 TPR，可以避免触发 VM exit。同时执行控制区还有一个 TPR 阈值的设置，只有当 Guest OS 设置的 TR 值小于该阈值时，才触发 VM exit。
CR masks and shadows：每个控制寄存器的每一位都有对应的掩码，控制 Guest OS 是否可以直接写相应的位，或是触发 VM exit。同时 VMCS 中包括影子控制寄存器，Guest OS 读取控制寄存器时，硬件将影子控制寄存器的值返回给 Guest OS。
VMCS 还包括一组位图以提供更好的适应性：
Exception bitmap：选择哪些异常可以触发 VM exit，
I/O bitmap：对哪些 16 位的 I/O 端口的访问触发 VM exit。
MSR bitmaps：与控制寄存器掩码相似，每个 MSR 寄存器都有一组“读”的位图掩码和一组“写”的位图掩码。
每次发生 VM exit时，硬件自动在 VMCS 中存入丰富的信息，方便 VMM 甄别事件的种类和原因。VM entry 时，VMM 可以方便地为 Guest OS 注入事件（中断和异常），因为 VMCS 中存有 Guest OS 的中断描述表（IDT）的地址，因此硬件能够自动地调用 Guest OS 的处理程序。
更详细的信息请参阅 Intel 开发手册 [5]。
解决纯软件虚拟化技术面临的挑战
首先，由于新的操作模式的引入，VMM 和 Guest OS 的执行由硬件自动隔离开来，任何关键的事件都可以将系统控制权自动转移到 VMM，因此 VMM 能够完全控制系统的全部资源。
其次，Guest OS 可以运行在它所期望的最高特权级别，因此特权级压缩和特权级别名的问题迎刃而解，而且 Guest OS 中的系统调用也不会触发 VM exit。
硬件使用物理地址访问虚拟机控制块（VMCS），而 VMCS 保存了 VMM 和 Guest OS 各自的 IDTR 和 CR3 寄存器，因此 VMM 可以拥有独立的地址空间，Guest OS 能够完全控制自己的地址空间，地址空间压缩的问题也不存在了。
中断和异常虚拟化的问题也得到了很好的解决。VMM 只用简单地设置需要转发的虚拟中断或异常，在 VM entry 时，硬件自动调用 Guest OS 的中断和异常处理程序，大大简化 VMM 的设计。同时，Guest OS 对中断的屏蔽及解除可以不触发 VM exit，从而提高了性能。而且 VMM 还可以设置当 Guest OS 解除中断屏蔽时触发 VM exit，因此能够及时地转发积累的虚拟中断和异常。
--------------------------------------------------------------------------------
回页首
未来虚拟化技术的发展
我们可以看到，硬件辅助虚拟化技术必然是未来的方向。Intel-VT目前还处在处理器级虚拟化技术的初级阶段，尚需在如下方面进行发展：
提高操作模式间的转换速度。
两种操作模式间的转换发生之如此频繁，如果不能有效减少其转换速度，即使充分利用硬件特性，虚拟机的整体性能也会大打折扣。早期的支持硬件辅助虚拟化技术的 Pentium 4 处理器需要花费 2409 个时钟周期处理 VM entry，花费 508 个时钟周期处理由缺页异常触发的 VM exit，代价相当高。随着 Intel 技术的不断完善，在新的 Core 架构上，相应时间已经减少到 937 和 446 个时钟周期。未来硬件厂商还需要进一步提高模式的转换速度，并提供更多的硬件特性来减少不必要的转换。
优化翻译后援缓冲器（TLB）的性能。
每次 VM entry 和 VM exit 发生时，由于需要重新加载 CR3 寄存器，因此 TLB（Translation Lookaside Buffer）被完全清空。虚拟化系统中操作模式的转换发生频率相当高，因此系统的整体性能受到明显损害。一种可行的方案是为 VMM 和每个虚拟机分配一个全局唯一 ID，TLB 的每一项附加该 ID 信息来索引线性地址的翻译。
提供内存管理单元（MMU）虚拟化的硬件支持。
即使使用 Intel-VT 技术，VMM 还是得用老办法来处理 Guest OS 中发生的缺页异常以及Guest OS 的客户机物理地址到主机物理地址的翻译，本质原因是 VMM 完全控制主机物理内存，因此 Guest OS 中的线性地址的翻译同时牵涉到 VMM 和 Guest OS 的地址空间，而硬件只能看到其中的一个。Intel 和 AMD 提出了各自的解决方案，分别叫做 EPT（Extended Page Table）和 Nested Paging。这两种技术的基本思想是，无论何时遇到客户机物理地址，硬件自动搜索 VMM 提供的关于该 Guest OS 的一个页表，翻译成主机物理地址，或产生缺页异常来触发 VM exit。
支持高效的 I/O 虚拟化。
I/O 虚拟化需要考虑性能、可用性、可扩展性、可靠性和成本等多种因素。最简单的方式是 VMM为虚拟机模拟一个常见的 I/O 设备，该设备的功能由 VMM 用软件或复用主机 I/O 设备的方法实现。例如 Virtual PC 虚拟机提供的是一种比较古老的 S3 Trio64显卡。这种方式提高了兼容性，并充分利用 Guest OS 自带的设备驱动程序，但是虚拟的 I/O 设备功能有限且性能低下。为了提高性能，VMM 可以直接将主机 I/O 设备分配给虚拟机，这会带来两个主要挑战：1. 如果多个虚拟机可以复用同一个设备，VMM 必须保证它们对设备的访问不会互相干扰。2. 如果 Guest OS 使用 DMA 的方式访问 I/O 设备，由于 Guest OS 给出的地址并不是主机物理地址，VMM 必须保证在启动 DMA 操作前将该地址正确转换。Intel 和 AMD 分别提出了各自的解决方案，分别称为 Direct I/O（VT-d）和 IOMMU，希望用硬件的手段解决这些问题，降低 VMM 实现的难度。