作者 主題: [軟體技術]x86虛擬化簡介:以VMware GSX Server為例  (閱讀 4877 次)

0 會員 與 1 訪客 正在閱讀本文。

carejollg

  • 可愛的小學生
  • *
  • 文章數: 5
    • 檢視個人資料
(說明)這篇文章原本先發表在PCDVD論壇,轉貼到酷!學園請網友指教;VMware GSX Server已更名為VMware Server,但不影響文章要闡述的概念。

原文章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

回到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「完整地」虛擬硬體裝置。

◎Hosted VM的效率問題
從圖2可以看到,VMMonitor與Host OS在同一個特權階層(Privileged-mode),都可以直接與硬體溝通。在x86虛擬化上,VMM(例如VMware GSX Server)與Host OS(例如Linux、Windows)是由兩家不同廠商各別開發的產品,以致於兩者有可能相互競爭底層硬體資源,並且缺乏衝突協調功能,造成運作效率低落。這也就是文章開頭提到,兩個作業系統都在作相同的事,卻沒有仲裁者,可能的例子像是暫存器因為Host OS與虛擬機器而不斷地改寫,或用於記錄虛擬機器狀態的分頁(Page)持續地產生分頁錯誤(Page Fault),處理器將會花更多時間在重新配置記憶體分頁。此外,如果VMM與OS兩個產品未經過資訊安全上的整合,則VMM可能變成Host OS上的一個資安漏洞。

◎結論:虛擬化其實是分時(time-sharing)作業系統所展現的一種用途,讓應用程式/虛擬機器可以短暫地擁有硬體資源,達到多工的錯覺。只是現在將應用程式換成是虛擬機器而已,彷彿各部虛擬機器可以擁有獨立的硬體一樣。然而,從文章內容所談論的技術,虛擬機器不必為了這個目的而模擬完整的硬體,只需要呼叫Host OS所提供的介面服務即可,同時也解決硬體相容性問題。雖然從使用者角度來看,好像在虛擬機器中操作真實的硬體(例如硬碟讀、寫)一樣,但這些硬體可能連「模擬」都稱不上。

化解硬體相容性之後,虛擬機器可以任意地在各種IA-32相容性平臺上遷移,這是虛擬化用於伺服器集中管理的重要實作方法,例如微軟已經不支援的Windows 98/95,但還有部份應用程式限制用在Win98/95,而硬體驅動程式則決定應用程式是否能延續其生命週期的關鍵。虛擬化並不是提供驅動程式的解決方案,而是呼叫抽象化介面所需的服務,以致於Win98/95從實體到虛擬化遷移過程中,我們不用擔心硬體驅動程式的問題。

從文章中描述的原理,似乎指出虛擬機器比較有效率的方式,是在IA-32架構中模擬IA-32架構的平臺,雖然現在虛擬化軟體可以模擬其他平臺的系統,可是效率可能不如IA-32架構。(不知道這是不是Apple決定使用Intel處理器的原因之一?)此外,在硬體支援下(64位元處理器與晶片組等),則可以在32位元的作業系統下模擬64位元的虛擬機器,只不過我無法確認是不是所有作業系統都適用這個原則,除非大量測試。

◎補充:特權階層的別名
分時作業系統設計時,為了讓各個應用程式在共用資源時,並避免相互干擾,所以運作時至少需要2種模式,也就是使用者模式(User-mode)與特權模式(Privileged-mode),後者也稱為系統模式(System-mode)、監督模式(Monitor-mode)、Supervisor-mode。為了與這些名稱比較,所以虛擬機器在特權階層運作的部份稱為VMMonitor或Hypervisor。
圖9中所使用的Ring 0/1/2/3也稱為Privilege 0/1/2/3。