原文章PDF下載位址

◎標題：[軟體技術]x86虛擬化簡介：以VMware GSX Server為例
◎前言：對於常需要多種作業系統的使用者，虛擬化免除辛苦的硬體安裝與搬動等工作。看似將Linux上安裝Windows、或在Mac OS開啟Windows，卻不用更動開機磁區(MBR)就是虛擬化。其實背後有許多看不見的軟體服務，如果沒有理解這些服務，會讓人們對虛擬化有過高的期望；請記得，x86虛擬化與真實主機還是有差距，並且不完美。或者說，從個人電腦使用者的角度來看，應該用「沙盒(SandBox)」形容虛擬化是頗貼切的描述。

這篇文章簡介x86虛擬化技術所採用的軟體服務，讓人們在應用虛擬化時，更能理解每一個操作的意義。附帶說明，文章所提到的VMware產品並不是替廠商****，只是因為x86虛擬化市場中，VMware是極早實作出量產的軟體產品，目前GSX Server/Workstation用戶也不少，因此技術文件也容易取得。

相關資料除了Wiki與VMware官方網站，還有在簡介AMD NPT/Intel EPT時所提過的「恐龍書」(作業系統)，網友也可以參考嚴謹的原文書：「Virtual Machines」，作者是James E. Smith與Ravi Nair。此篇文章中所用的圖與文均來自上述公開資料。

◎虛擬化分類：Native/Hosted VM System(上)

VMware GSX_1.tif

圖左是真實主機的簡略圖解，底層是硬體(Hardware)；最上層是應用程式(Applications)，在Intel IA-32架構中的4個特權階層中，應用程式位於Ring 3，這一層不允許執行某些對硬體任意更動的指令，例如寫入暫存器位元；中間是作業系統(OS)，圖中標示出其Ring 0的特權階層，負責分配底層硬體資源給上層各個應用程式，用於保護與隔離各個應用程式，避免相互競爭硬體資源。

在IA-32架構中還有Ring 1/2這兩層，Device-Driver、Library Routines等指令集便位於這兩層，主要是為延伸作業系統與應用程式溝通時的服務。IA-32這樣的架構設計有其歷史淵源，在個人電腦上也延用一段長時間，但在虛擬化時增加實作上的困難與複雜。我們常用來與x86虛擬化比較的是IBM System/370主機的VM架構，後者只有兩個特權階層：分別是Privilege/Non-privilede。在初期設計就考量到主機運算資源運用最大化(早期運算資源非常昂貴)，所以VM/370這種虛擬化就已納入考量。x86平臺則是為泛用型的個人電腦而設計，並沒有考量到往後虛擬化應用，但更動架構設計不是一家廠商願意冒險且獨力完成的工程，以致於VMware這類供應商得面對軟體實作上的困難。

網友可以參考早期Kevin P. Lawton所寫的「Running multiple Operating Systems concurrently on an IA-32 PC using virtualization techniques」研究，文章內提到x86架構不適合用於虛擬化的原因，以及IA-32的特權指令在虛擬化過程中得特別處理方法。雖然現在已經有x86虛擬化相關的產品，卻是VMware、Virtual PC、Xen這類軟體所支撐起來。
AMD/Intel在新一代處理架構中增加虛擬化硬體輔助指令，其實是因為這類處理器常被當成企業用入門的伺服器，這塊市場的經濟規模可觀，AMD/Intel不得不在x86虛擬化上推出新指令以應用未來潛在的市場。

目前個人電腦也可以應用虛擬化，則是消費者間接獲益的結果。另一個推動力量則是開放原始碼的虛擬化軟體(XenSource、VirtualBox等)。特別是XenSource的快速掘起，因為個人電腦光有硬體是不夠的，而且VMware還有昂貴的授權使用費，競爭結果才讓VMware與微軟快速降價，使用者則撿到便宜。好比同軸電纜發展過程中，因為HBO掘起才促成有線電視的普及，不然現在我們還過著在風雨交加的天氣中，在屋頂搖電視天線的日子。現在軟體工程師不用再兼硬體黑手，拿著手電筒躲在烏黑的桌下拆裝硬體，只為了安裝一個網頁或應用伺服器，如今他們終於可以優雅地搖者滑鼠，就有檔案伺服器、網頁伺服器與資料庫。

◎(接上一段)虛擬化分類：Native/Hosted VM System(下)
作業系統有BSD、Linux、Solaris與Windows等不同產品，虛擬化市場也有眾多玩家與分類。一般我們常稱的虛擬化是所謂的System Virtual Machine，架構上簡略區分為圖1中的2大類：Native與Hosted VM，兩者的區別只在於前者的VMM完全控制硬體，後者由Host OS控制硬體。Hosted VM再細分為User-mode與Dual-mode。

Native VM與Para-virtualization在概念上是相似的，其VMM是簡化的OS核心(通常是Linux核心)，沒有Host OS般包山包海的用途。XenSource算是這類技術的著名的產品，優點是讓虛擬化效率損耗降得最少；現在更在VT-x/Pacifica輔助下，Guest OS可以停留在Ring 0，不用降為Ring 1；簡單地形容，Guest OS幾乎無法感受到自己已「被虛擬化」。不過少了Host OS輔助，使Native VM的VMM對硬體相容性較低。較早時還有另一個缺點，虛擬機器所使用的Guest OS必須針對VMM修正其核心，也就是不能安裝零售版的Windows做為虛擬機器。(在VT-x/Pacifica輔助下，已經可以安裝市售的Windows)

再看到圖1右的Hosted VM，Host與Guest各有一個完整的作業系統，並且是一般零售就能取得的軟體產品，但從硬體的角度來看，這兩個作業系統都在執行相同的工作，以致於效率較差。不過，優點是Host OS對硬體相容性較高，這一點在「硬體相容性與驅動程式：以I/O虛擬化為例」會更清楚地說明。

我們可以比較Traditional System與User-mode Hosted VM，VMM、Guest OS/Applications整個可以看成是Host OS上的一個應用程式，同樣都在真實環境的Ring 3(或者是User-mode)執行，這是效率損耗的原因。事實上，我們在Linux/Windows上安裝VMware GSX Server/Workstation，也像是安裝一個應用程式一樣，操作時需要就開啟、不用便關閉。

◎以VMware GSX Server為例

VMware GSX_2.tif

VMware GSX Server屬於圖2中Dual-mode Hosted VM，理論上這種虛擬化的VMM由3個部份組成：VMM-n(n是native簡寫)、VMM-u(u是user簡寫)、VMM-d(d是driver簡寫)。從架構組成可以理解VMM有一部份在User-mode，有一部在Native-mode，這是Dual-mode Hosted VM名字的由來。

VMware GSX Server的VMM可以細分為3個部份，VMMonitor(對應理論中的VMM-n)與Host OS同在Ring 0，用途是監視虛擬機器所發出的特權指令；VMApp(對應理論中的VMM-u)則與Host Applications同在Ring 3，將虛擬機器所發出的要求(Requests，例如Memory、I/O等)傳遞到Host OS，再傳遞到硬體。

VMMDriver的特殊角色讓人覺得有點多餘，為何虛擬機器不能直接將要求由VMMonitor傳遞到Host OS？前面提到Hosted VM中VMM相當於Host OS中的一個應用程式，再回到圖9的IA-32架構，應用程式所發出的特權指令得傳遞到Ring 0的作業系統處理硬體資源，中間經過Ring 1/2，也就是Device-Drive或Library Routines。

(IA32 Privilege Rings.tif)
AMD NPT_2.tif

回到VMware GSX Server，虛擬機器也是透過相似應用程式的程序。我們可以將VMMonitor看成作業系統中的一個裝置(Device)，這個裝置則是虛擬機器需要底層硬體時的一個抽象化(透過VMMApp)，而VMMDriver相當於特殊的Device-Driver，也就是溝通VMApp與VMMonitor這兩個部份。

◎硬體相容性與驅動程式：以I/O虛擬化為例
不過，虛擬機器需要硬體資源時，並不需要真的在VMM中安裝驅動程式，只需利用已存在Host OS中的函式庫(System Library)。

Linux Architecture_1.tif

參考圖3中真實的Linux架構。最上層是應用程式(Applications)，Memory、I/O等要求傳遞到Kernel-mode的作業系統處理時，有兩條路徑：函式庫(Libraries)與System-Call Interface。虛擬化時的VMM也可利用這兩條已存在的管道，由作業系統的函式庫提供硬體所需的服務，但不用真的安裝Device-Driver，虛擬化軟體供應商也不用自行開發驅動程式。

圖4以VMware GSX Server更進階地說明I/O虛擬化。

IO virtualization_1.tif

I/O裝置有磁碟(IDE/SCSI)、CD/DVD-ROM、網路卡、音效卡、平行埠、序列埠等，不但種類非常多，廠商也眾多。這使得IA-32架構為了處理硬體相容性變得非常困難，因為每一種I/O裝置都得撰寫驅動程式，並編譯、封裝到作業系統中。廠商每次推出新裝置，作業系統就必須封裝一次，連虛擬機器的Guest OS也一樣，系統的維護變得沒有效率。

IA-32為解決硬體相容性問題，首先要求在I/O裝置上建立共通的工業標準，例如硬碟與光碟機雖然儲存方式不同(磁性與光學)，但都使用相同的IDE介面。接下來，作業系統則在硬體上增加一個抽象層(Abstraction Layer)，用於作業系統與底層硬體間溝通所需的共同介面。在IA-32架構實作時，稱為HDI(Hardware Device Interface)，所有硬體相關(Device-dependent)的指令都在抽象層完成，作業系統只要知道從HDI提供哪些函式庫服務。這個過程也就是所謂的硬體抽象化。

同樣地，虛擬機器也遇到同樣的硬體相容性問題。既然Host OS已經有現成的函式庫服務，VMware這類廠商也不用再自行開發驅動程式，取代的是與HDI相似功能的VDI(Virtual Device Interface)。從虛擬機器來看，彷彿所有硬體相關的指令已經由Host OS做完了，Guest OS只要知道VDI提供哪些函式庫服務，就可以取得硬體資源。簡單地說明整個過程是：VDI→VMM→HDI(VMware GSX Server則參考圖4)，而且只傳遞呼叫介面服務所需參數。在IA-32架構中的Windows，則是win32這類的System Call，不用反複地轉譯指令。

硬體抽象化可以降低虛擬化的複雜度。記得圖3中我們將應用程式類比成虛擬機器，Kernel-mode則類比Host OS，而在Kernel-mode中透過File Subsystem這個抽象層，取得各種儲存裝置資源，但不用關心這些儲存硬體到底是硬碟或光碟機。相似的原理，藉著File Subsystem所提供的函式庫服務，虛擬機器可以應用這些服務來模擬IDE/SCSI硬碟(不用關心到底是哪一種硬體)，所以在虛擬機器中所看到的硬碟(參考Windows Devices_1圖)，其實只是Host OS中的一個檔案，既然是可以任意更動的檔案，就可以用來陰影複製(Shadow Copy)、復原點(或Undo Disks)等，這也是虛擬化受到許多開發工程師愛用的原因。


Windows Devices_1.tif

在虛擬機器的實際操作中，我們可以看到Guest OS中列出的各項硬體裝置，雖然也知道實際上並沒有存在這些硬體，但人們還誤以為VMware「完整地」虛擬硬體裝置。