顯示文章

這裡允許您檢視這個會員的所有文章。請注意, 您只能看見您有權限閱讀的文章。


文章 - carejollg

頁: [1]
1
原文章PDF下載位址,原本先發表在PCDVD,轉載到此論壇,請網友指教。

◎標題:[硬體技術]記憶體管理虛擬化:AMD NPT/Intel EPT簡介
◎前言:在x86架構中,記憶體分頁(page tables)是用來保護記憶體位址,使記憶體在多個程式存取時不互相干擾。然而,記憶體分頁在虛擬化時,得經過VMM(或稱為Hypervisor)中SPT(Shadow Page Table)的轉換,造成效能損耗。如果轉換過程未精確地控制,可能讓虛擬機器中Guest OS所發出的特權指令未適當地產生中斷與例外處理,如果這部虛擬機器是電子商務伺服器,結果是一筆交易資料莫名地消失了,而且事後追查問題根源的難度非常高。

目前,AMD/Intel都提出各自的記憶體分頁虛擬化機制,AMD稱為NPT(Nested Page Tables)而Intel稱為EPT(Extended Page Tables),兩者的運作概念是相同的。這篇文章將簡介相關的原理,並讓網友了解目前x86虛擬化的困難與廠商的處理技術。(相關資料都可以在AMD/Intel官方網站的公開資料找到)

◎AMD NPT中虛擬化的記憶體位置轉換(address translation)
AMD NPT_2.tif
記憶體轉換過程可以先參考下一段所敘述,未虛擬化時的記憶體轉換程序(圖1)。
上圖2中,右側列出Para-virtualization概念圖,並以紫色線段區隔Guest OS與VMM,更詳細的虛擬化圖解請參考段落結束的圖3。

NPT(Nested Page Tables)機制將記憶體轉換過程縮減為2階段。
首先,在Guest OS中(圖2中紫色線段區隔的上半部),當系統開啟一個行程(process)時,作業系統會為這個行程配置一個分頁表。此時,Guest記憶體的線性位址(Guest Linear Address)透過 gPT (Guest Page Tables)映射到Guest的實體位址(Guest Physical Address)。其分頁表(gPT)位於Guest的實體記憶體中,gCR3(Guest中的CR3)相當於硬體的暫存器,負責執行Guest OS中的映射作業。
接下來,藉著實體記憶體中的nPT(nested page tables),將Guest記憶體的實體位址映射到系統的實體記憶體位址。網友可以注意到nPT位於實體記憶體中,硬體上則由nCR3(相對於Guest,nCR3可看成是Host OS中的CR3)負責執行映射作業。

gCR3僅負責管理Guest OS中,記憶體由線性位址(Guest Linear Address)映射到實體位址(Guest Physical Address),其機制與未虛擬化的實體主機相同,網友可以參考下一段落的圖1與說明。在NPT的機制中,如果要存取Guest OS中的記憶體分頁時,Guest的實體位址會先被轉換到系統的記憶體位址(System Physical Address)。如果是從Guest的記憶體線性位址映射到實體記憶體,便以快取的方式記錄在TLB中。

NPT的兩階段記憶體轉換,特點就是將Guest Physical Address→System Physical Address,VMM不用再保留一份SPT(Shadow Page Table),以及以往還得經過SPT這個轉換過程。除了降低各部虛擬機器在切換時所造成的效能損耗外,硬體指令集也比虛擬化軟體處理來得可靠與穩定。

相關資料可以在Google找到外,或者網友可以參考「2007XenSummit-AMD-Barcelona_Nested_Paging_WahligHuang.pdf」這份簡報檔。簡報中提到AMD在Barcelona中已內建NPT指令集,虛擬化軟體方面,Xen 3.0.5版已支援此機制。
AMD NPT_3.tif

◎傳統(未虛擬化)的記憶體位置轉換(address translation)
AMD NPT_1.tif
圖中顯示記憶體位址(address)轉換時,將線性位址(Linear Address)透過分頁表(PT,Page Tables)所記載的內容,映射到實體位址(Physical Address)。其中CR3(Control Register)是一組硬體暫存器,負責執行映射作業並提升記憶體位址轉換效率所需的指令。

◎Intel EPT中虛擬化的記憶體位置轉換(address translation)
Intel EPT_1.tif
圖4簡介Intel EPT概念,原出處是「Intel Virtualization Technology Processor Virtualization Extensions and Intel Trusted execution Technology.pdf」。
為了方便說明Intel EPT與AMD NPT機制在原理上相同,所以改成圖5的解說。網友可以將圖5與圖2做比較,兩圖的差異在圖5中紅色字的部份,這4個紅色字則來自於圖4。
圖5中紅色字的「CR3」其實是圖2的「gCR3」,都是Guest OS的CR3;而圖5「EPT Base Pointer」則是圖2的「nCR3」,相當於Host OS的CR3;接下來,圖5的「Guest Intel 64 Page Tables」對應到圖2的「gPT」;最後,圖5中紅色字的「EPT」相當於圖2的「nPT」,也就是AMD NPT所使用的巢狀分頁表(nested page tables)。

Intel EPT與AMD NPT都是將Guest Physical Address映射到System Physical Address,不經過VMM中的SPT,均是兩階段轉換,目的也是為了降低記憶體轉換時在VMM所產生的效能損耗。

◎簡介記憶體分頁的效能問題
VT-x.tif
藉著Intel簡報內的圖解,簡單說明記憶體分頁在虛擬化所造成效能降低的過程。
圖中可以看到用戶在操作多部虛擬機器時,其實是不斷地在各部虛擬機器間來回切換,每一個切換過程包括「VM Entry」與「VM Exit」,並產生記憶體分頁。這些記憶體分頁記錄著虛擬機器當時的狀態,並由VMM負責管理與轉換各部虛擬機器所產生的分頁。

其實,這也是一種記憶體保護機制。我們可以對照在真實主機中操作時,多個行程(或應用程式)在存取記憶體時,作業系統透過分頁機制保護每個行程所需的記憶體空間。這種類比下,多部虛擬機器就好像多個行程/應用程式一樣,而VMM就相當於作業系統。多部虛擬機器在VMM中切換,就如同多個行程/應用程式在作業系統中切換一樣,差別在於分頁內容不同。因此,作業系統能更有效率地管理記憶體分頁,便可以讓各個行程切換更有效率。同樣的效率瓶頸在虛擬化時,就在VMM如何有效地管理記憶體分頁(請參考圖8中的示意圖)。
Memory Management_s.tif

不過,虛擬化後記憶體管理變得很複雜,況且還有分頁錯誤(Page Fault)、中斷(Interrupt)與例外處理(Exception Handler)等。在沒有硬體輔助指令前,由Xen、VMware等虛擬化軟體負責記憶體管理所有事項,當伺服器虛擬化集中管理時,VMM就可能讓虛擬機器間切換變得緩慢。同樣地,一般實體主機的應用程式開得很多時,用戶也會感覺到應用程式在切換時,效率越來越差,或者開啟多個大量耗用記憶體的應用程式(例如Photoshop),作業系統運作遲鈍等。對記憶體所有存取動作都需要經過分頁映射,所以映射效率決定虛擬機器切換的效能,AMD NPT/Intel EPT便是透過硬體輔助指令降低記憶體管理在虛擬化的效能損耗。

◎結論:等待市場驗證;下一階段,I/O虛擬化與資訊安全
雖然AMD/Intel提供記憶體管理所需的硬體輔助指令,但還需要虛擬化軟體供應商整合,因為每個虛擬化軟體中VMM對記憶體管理的機制並不一定相同,就好像實體主機中,Linux與Windows對記憶體管理也不同。當軟體和硬體整合後,還得經過實際環境應用的驗證,才知道新技術的可靠度與穩定性。

在實體主機上,記憶體管理都經過多年的驗證與不斷地修正,不論是AMD/Intel硬體架構或Apache、Oracle Database、SAP ERP等各種伺服器,才有如今的可靠與穩定。可是在虛擬化過程中,這些機制還是很新穎的技術,有待市場驗證。這是虛擬化應用的潛在風險,在未成熟的情況下,效率是用預算堆出來的,不是一般用戶能負擔的價格。
至於驗證的技術,需要對作業系統有深厚的瞭解(VMM具備Host OS的核心功能,也是一個簡化的作業系統),才能在檢驗過程中,追蹤系統呼叫(system call)在作業系統中是否精確地處理。我自認學識淺薄,沒有這方面的技術,還希望有此能力的網友指教。

Ring 0除了記憶體管理,另一個重要機制就是檔案管理(File Management),這關係著I/O虛擬化指令集。AMD/Intel都將在未來的平臺中納入相關的輔助指令,以及虛擬化軟體整合後與實際運作的驗證。(請參考圖9)
IA32 Privilege Rings.tif
此外,虛擬化成熟後,資訊安全也會形成另一個重要議題。從圖3中可以察覺到VMM處於Ring 0,也就是特權指令所在的階層,一但取得VMM控制權,等於掌控所有虛擬機器。舉例來說,讀、寫分頁表暫存器等指令都是特權指令,也就是在VMM中才可以執行,任意改變分頁表暫存器就可隨意中止某個行程。此時,即使虛擬機器安裝防火牆等系統,也不至連VMM都阻擋吧。這種情況下,防火牆如同虛設般。資訊安全與I/O虛擬化將是下一階段重要議題,有待軟、硬體廠商提出新的解決方案。

2
原文章PDF下載位址,檔名是「VMware ESX Server」,檔案大小約2.18MB。(原文發表在PCDVD,轉載到此論壇,請網友指教)

◎標題:[軟體應用]資訊基礎架構虛擬化:VMware ESX Server 3.5 (2008/4/9)

◎前言:(抱歉,文章內沒有效能測試,原因是使用個人電腦建置軟體應用參考環境,而不是企業用伺服主機)
VMware ESX Server定位在中、大型資訊架構虛擬化,與(GSX)Server/Workstation著重在中、小型資訊系統或個人工作站等不同,這2類軟體所使用的虛擬化技術與管理概念也有極大的差別。開始前建議網友先具備基本的作業系統與Linux套件等管理基礎。

這篇文章的目的將簡介ESX Server應用在基礎架構虛擬化所使用的概念與技術,包括資源中心(Resource Pool)、儲存架構(Storage Architecture)、微核心(microkernel)與Hypervisor、VMFS3虛擬檔案系統、VMI 3.0等;除了基本的ESX Server安裝步驟外,文章也將簡介ESX Server的3種管理工具:VMware Infrastructure Client、VMware Infrastructure Web Access、VMware Service Console。

網友對VMware Server/Workstation應不陌生,但ESX Server則是完全不同的虛擬化系統,以下是簡略說明。ESX Server採用Native Virtualization(VMware稱為Transparent Para-virtualization)技術,在實際應用上注重穩定、資訊安全、擴充性,並將底層的伺服器統合成叢集(Clusters),再抽象化、集合成可分割運算資源的Resource Pool;虛擬機器則由這個資源中心取得運算資源,可以理解ESX Server在用途上將改變資訊基礎架構的伺服器服務與管理方式;相對地Server/Workstation則以相容性、容易操作、彈性(泛用性)為主,負載虛擬機器數量較低,但適用於各種市面常見的作業系統,以致於常用於軟體工程師所需的測試工作站。

VMware已經將ESX Server納入VMware Infrastructure虛擬化解決方案,並成為套裝產品之一。顧名思義,這是在資訊基礎架構上應用虛擬化,再衍生出伺服器集中管理、備份、災難復原等多種用途。基礎架構虛擬化與傳統上一個服務配置一部伺服器的用法不同,而且ESX Server的Hypervisor虛擬層架設在基礎硬體(如叢集伺服器、GbE網路、SAN儲存系統等)上,使得底層的資訊基礎設施變得抽象化,使資訊人員得重新學習管理虛擬伺服器的相關技能。文章中將簡略揭露其原因。

◎軟體、硬體需求

硬體:準備2部主機,分別是伺服器與遠端管理主機。伺服器安裝VMware ESX Server 3.5系統,遠端管理主機則安裝Virtual Infrastructure Client/Web Access與Server Console(提供Service Console服務)所需的相關工具。硬體需求請參考下一節文章中的架構圖。
軟體:VMware ESX Server 3.5(官方網站下載),只須下載第一個檔案,其餘檔案用於更大型的架構。下載後是一個ISO檔,再燒錄成可開機光碟即可;至於Virtual Infrastructure Client/Web Access與Server Console則由ESX Server部署即可,不用額外下載軟體。

◎硬體配置(VMware ESX Server 3.5參考架構)

VMware ESX Server最低要求的基本架構需要兩部主機,這裡所使用的架構範例與之前文章中提到的Virtual Iron參考架構相同,除了VMware ESX Server 3.5伺服器與遠端管理電腦,更複雜的架構可以增加VirtualCenter Database、VirtualCenter Server與SAN儲存裝置等獨立伺服器,只是所需硬體已超過我的主機數量,暫時不在此文的討論範圍。

各主機硬體配置與網路設定請參考下圖:

ESX Server Reference_1.tif

伺服器在安裝前,建議備份硬碟資料,安裝時磁碟會被格式化為ext3/VMFS3檔案格式,後者是ESX Server專屬的檔案格式。至於處理器的需求,VMware官方網站的新功能新功能並沒有列出與AMD Pacifica/Intel VT-x相關的項目,但技術文件中提到3.5版已支援AMD NPT指令集(記憶體分頁虛擬化)。網友應該可以使用未內建Pacifica/VT-x指令集的主機做為伺服器,但我並未測試沒有硬體輔助指令下的安裝方案,請其他網友分享這方面的經驗。

範例中使用的伺服器,其處理器有內建AMD Pacifica指令並在BIOS啟動,安裝時沒有發生問題。技嘉MA78GM-S2H主機板可安裝ESX Server 3.5,但不支援內建的IDE/SATA控制晶片,所以IDE/SATA硬碟無法辨識,改使用VMware建議的外加SCSI儲存裝置;另一點則是ESX Server也不支援主機板內建的網路控制晶片,所以額外加上Intel PRO/1000 MT的GbE獨立網路卡,否則遠端管理主機無法透過區域網路連接伺服器。

遠端管理主機只要一般安裝Windows XP的個人電腦或筆記型電腦即可,圖示也說明兩部主機透過10/100 Ethernet Switch連接;如果遠端管理主機使用Linux套件,須改用Web Access的方式連接伺服器。

◎VMware ESX Server 3.5安裝步驟

以下是VMware ESX Server 3.5安裝畫面,只要硬體沒有相容性問題,安裝過程會自動執行。
這些步驟與安裝Virtual Iron、Citrix XenServer、甚至Linux套件等相似,熟悉以上軟體的網友可以跳過這一小節。
因為安裝過程缺少截圖的工具,以下圖檔來自於TrainSignal安裝3.0版教學圖檔,與範例所使用的3.5版大同小異。

ESX_install_1.png
(圖說)以ESX Server安裝光碟開機後的畫面。

ESX_install_2.png
(圖說)檢查安裝光碟,如果確認沒有問題,可以選擇跳過(Skip)。

ESX_install_3.png
(圖說)(略)

ESX_install_4.png
(圖說)(略)

ESX_install_5.png
(圖說)選擇鍵盤。

ESX_install_6.png
(圖說)選擇滑鼠。

ESX_install_7.png
(圖說)版權宣告。

ESX_install_8.png
(圖說)圖中列出可使用的儲存裝置,由於範例的伺服器僅辨識出SCSI卡上的硬碟,所以安裝時只能選擇SCSI硬碟(範例中為36GB)。
磁區分割方式選擇建議值(Recommanded),系統會分割出必要的磁區,待熟練後可改用進階方式(Advanced)。

ESX_install_9.png
(圖說)選擇建議值分割磁碟的結果。圖中所列都是必要的磁區,在進階方式分割時可以參考。

以下是範例所使用36GB SCSI硬碟分割值:

/boot      (101 MB)
/         (4996 MB)
vmfs3    (27266 MB)
swap       (541 MB)
/var/log  (1992 MB)
vmkcore    (101 MB)

除了開機磁區(/boot)、根目錄(/)、swap與log磁區外,vmkcore是用於系統維護與除錯用的;剩下的磁碟空間將會分割成VMFS3的檔案格式,用於儲存虛擬機器的檔案,數字3代表第3版的VMFS。
若使用進階方式分割,其他自訂的分割區,例如:/home、/tmp、VFAT(用於映射到RAW Disks)

ESX_install_10.png
(圖說)安裝MBR(開機管理員)

ESX_install_11.png
(圖說)網路設定,以下是範例所使用的設定:

IP Address:192.168.10.10
Subnet Mask:255.255.255.0
Gateway:192.168.10.255
Primary DNS:192.168.10.1

ESX_install_12.png
(圖說)選擇時區。

ESX_install_13.png
(圖說)這裡請輸入Root管理員密碼,這是VMware Infrastructure Client所需的密碼。

ESX_install_14.png
(圖說)安裝前確認所有設定值,接下來將開始安裝。

ESX_install_15.png
(圖說)安裝結束。

ESX_install_16.png
(圖說)伺服器會重新啟動,開機完成後的畫面如圖。圖中顯示伺服器所在的名稱與IP位置。

範例則是:http://192.168.10.10

圖中下方說明按下「Alt+F1」可以進入伺服器本機的管理終端機(Server Console)。

ESX_install_17.png
(圖說)按下「Alt+F1」進入Server Console終端機畫面。這個服務是由VMware ESX Server中的Service Console模組所提供的,而這個模組則是由Red Hat Linux所修改而成,表示終端機的指令與Red Hat Linux是相通的,Script指令也相同。

◎遠端管理主機(VMware Infrastructure Client,以下簡稱VI Client)安裝與設定

VI_Client_1.png
(圖說)開啟遠端管理電腦的瀏覽器,在網址列上鍵入伺服器位址:http://192.168.10.10
出現圖中畫面,接下來點選「Download VMware Infrastructure Client」,瀏覽器會下載「VMware-viclient.exe」的安裝檔案。

VI_Client_2.png
(圖說)下載後的「VMware-viclient.exe」安裝檔案,容量約為50.1MB。

VI_Client_3.png
(圖說)點選「VMware-viclient.exe」兩下後開始安裝VI Client。安裝過程很容易,不需要特別說明。

VI_Client_4.png
(圖說)(略)

VI_Client_5.png
(圖說)這裡請任意填寫。

VI_Client_6.png
(圖說)(略)

VI_Client_7.png
(圖說)(略)

VI_Client_8.png
(圖說)安裝完成後,桌面上會出現「VMware Infrastructure Client」的捷徑圖示,點選後進入管理介面。

VI_Client_9.png
(圖說)VMware Infrastructure Client的登入認證畫面,輸入VMware ESX Server安裝時設定的IP、管理員帳號(root)與密碼。

VI_Client_11.png
(圖說)VI Client的首頁。圖中左側的樹狀結構,請參考後續說明,其下已建立「Linux」、「Windows」等DataCenter,以及2部虛擬機器。
最上層代表Resource Pool的名稱,內定值是:「localhost.localdomain」
如果有網域控制站,請改用完整的網域名稱。
每一個樹狀結構的詳細資訊,會顯示在右側的頁籤面中。以下僅舉例簡介頁籤內容。

VI_Client_12.png
(圖說)在右側頁籤上點選「Summary」,顯示出伺服器的處理器、主記憶體、儲存裝置與網路等各種可用資源。

VI_Client_12_1.png
(圖說)點選「Virtual Machines」,列出目前在Resource Pool下所有虛擬機器與其狀態。
圖中的uBuntu_Server(含Desktop套件)與Vista(32位元)都只含作業系統,未安裝任何應用程式,網友可以比較一下處理器與記憶體的使用率。

VI_Client_13.png
(圖說)點選「Performance」頁籤,可以看到Resource Pool所屬的CPU、Disk、Management Agent、Memory、Network、System等使用率。

VI_Client_14.png
(圖說)點選「Configuration」頁籤,列出ESX Server的組態設定項目。圖中是目前Resource Pool的虛擬網路組態。

VI_Client_15.png
(圖說)(接上圖)點選「Configuration」→「Software」→「Security Profile」,進入ESX Server內建的防火牆選項設定。

VI_Client_16.png
(圖說)(接上圖)點選右上角的「Properties」,勾選啟動防火牆項目。

VI_Client_17.png
(圖說)虛擬處理器的使用率,這是管理員監控虛擬機器資源與狀態的報表。

VI_Client_18.png
(圖說)虛擬磁碟的使用率。

VI_Client_19.png
(圖說)虛擬記憶體的使用率。

VI_Client_20.png
(圖說)虛擬網路的使用率。

◎建立虛擬機器

VM_install_0.png
(圖說)點選樹狀目錄上的「localhost.localdomain」,按下滑鼠右鍵,在接下來的選單上選擇「New Virtual Machine」,建立虛擬機器。這個過程與VMware Server/Workstation都相同,熟悉這些步驟的網友可略過。

VM_install_1.png
(圖說)虛擬機器名稱,在ESX Server中建議使用有意義的名稱,容易辨識出Guest OS的種類或版本等,例如「uBuntu_Server」。此做法的概念與Virtual Iron相同,後續在各個VirtualCenter間遷移虛擬機器時,不致於混亂。

VM_install_2.png
(圖說)圖中顯示虛擬機器的儲存中心位置。在ESX Server中將儲存中心稱為Datastore,不論後端是本機的SCSI硬碟或SAN儲存系統,都被抽象化後改以名稱使用。圖右的[storage1]是SCSI硬碟的VMFS3分割區空間,也就是本機SCSI硬碟當成儲存中心。

如果安裝ESX Server時有辨識出IDE/SATA裝置,但這裡卻沒有顯示可用的儲存中心,這是因為VMware使用專屬的VMFS3檔案格式,對儲存裝置有特別的要求,細節可以參考「vi3_30_20_installation_guide.pdf」這份文件。建議最低需求為SCSI裝置,同時安裝ESX Server與虛擬機器。文件中特別說明IDE/SATA雖然可以辨識,但不能用來當成虛擬磁碟的儲存中心,即使在系統上將SATA模擬成IDE或SCSI硬碟也不行。

VM_install_3.png
(圖說)圖中是ESX Server所支援虛擬機器的Linux套件清單,較新的Red Hat Enterprise Linux 5、SuSE Linux Enterprise Server 10 SP2都在名單內;特別的是64位元的Linux套件,但處理器也必須有64位元與虛擬化指令集,才能安裝64位元虛擬機器。

VM_install_4.png
(圖說)圖中是VMware ESX Server所支援虛擬機器的Windows版本清單,除了Windows Vista與Server 2008都已經列入之外,64位元的Windows也在名單上,安裝條件與Linux相同。

圖中可以看到Windows NT 4以前的舊版本已不在支援的項目,所以使用Windows 98/ME等系統虛擬化得改用其他產品。

VM_install_5.png
(圖說)因為伺服器主機使用雙核心的AMD處理器,所以虛擬機器最多也只能有2顆虛擬處理器(vCPU)。

VM_install_6.png
(圖說)虛擬機器主記憶體容量設定。VMware ESX Server允許記憶體「over-commitment」;例如實體記憶體共2GB,但可以安裝4部虛擬主機,每部配置1GB、一共4GB的虛擬記憶體。
3.5版也可支援AMD Nested Page Tables(NPT)的記憶體分頁虛擬化指令。

VM_install_7.png
(圖說)設定虛擬網路卡,每部虛擬機器最多可安裝4張虛擬網路卡。

VM_install_8.png
(圖說)I/O控制卡選項。如果安裝虛擬機器後卻無法啟動或找不到虛擬磁碟,這裡是可能的問題來源之一,將LSI Logic改成BusLogic,或者改用相反的設定。

VM_install_9.png
(圖說)設定虛擬磁碟。如果後端儲存裝置是使用SAN儲存系統,這裡可以透過「Raw Device Mapping」將磁區掛載到ESX Server上。

VM_install_10.png
(圖說)虛擬磁碟容量與儲存位置。
如果有安裝另一部VirtualCenter Server,可以選擇「Specify a datastore」,將虛擬磁碟儲存到後端的Datastore。範例中僅使用單機硬碟,所以選擇第一項。

VM_install_12.png
(圖說)虛擬磁碟進階設定,勾選下方的「Mode」,可以選擇關機後不儲存虛擬磁碟的任何更動,就像學校電腦教室常用的時光還原功能一樣。

VM_install_13.png
(圖說)設定完成,這裡列出虛擬機器所有資源。

VM_install_14.png
(圖說)下方的「Add」、「Remove」可以新增或刪除特定裝置。建議刪除不用的序列埠、串列埠、軟碟機、音效裝置等。
如果選擇使用實體光碟機開機,請記得在「New CD/DVD」勾選「connect at power on」。

VM_install_15.png
(圖說)在「Options」頁籤上,可以看到「Para-virtualization」、「Virtualized MMU」、「Swapfile Location」等比較特別的設定。
Para-virtualization僅支援kernel 2.6.21以上的Linux套件,如果作業系統本身不支援這項功能,啟用後不會有任何效果。啟用後Guest OS可以透過VMI(Virtual Machine Interface)與VMM溝通,降低指令轉譯的效率損耗。

VM_install_16.png
(圖說)記憶體分頁虛擬化的設定,如果使用內建NPT指令集的AMD處理器,可以在此設定ESX Server的Hypervisor是否應用這些指令,降低虛擬機器切換的效率損耗。

VM_install_17.png
(圖說)完成後會在樹狀目錄下出現虛擬機器的名稱。

VM_install_18.png
(圖說)虛擬機器的螢幕畫面在頁籤列的「console」。

◎VMware Infrastructure Web Access

Web_Access_0.png
(圖說)VMware ESX Server另外提供Web Access的虛擬機器管理方式,與VI Client相比,功能較為簡潔,只提供虛擬機器所需的基本管理功能,並使用瀏覽器即可。
如果遠端管理主機是Linux,只能選擇Web Access方式,因為VI Client僅支援Windows。
點選「Log in to Web Access」。

Web_Access_1.png
(圖說)認證畫面。

Web_Access_2.png
(圖說)FireFox瀏覽器安裝Plug-in的提示,選擇「Install Plug-in」。

Web_Access_3.png
(圖說)圖中是Web Access的畫面,只看到虛擬機器相關的管理項目,Resource Pool相關的設定就省略,或透過VirtualCenter Server整合,再透過VI Client管理。

Web Access限制只能連接一部ESX Server,所以樹狀目錄最上層的是ESX Server單一主機的名稱,下一階是這部伺服器內部擁有的虛擬機器。我們可以把Web Access看成用來管理ESX Server群中的單一部虛擬機器工作站,有點像是VMware的 Workstation版。

◎VirtualCenter Database遠端管理

Web_Access_8.png
(圖說)在VI Client的瀏覽器畫面,點選「Browse datastores in this host's inventory」,可以用於管理VirtualCenter Database中的虛擬磁碟檔案(Database本身沒有遠端管理介面,須透過VirtualCenter Server)。
由於範例中沒有獨立的VirtualCenter Server,所以將ESX Server本機當成Datastore。

Web_Access_9.png
(圖說)因為範例所使用的參考架構不包括獨立的VirtualCenter Server與Datastore,所以接下來看到的是本機的儲存中心,名稱是「storage1」。

Web_Access_10.png
(圖說)這個儲存中心內建立2個VirtualCenter,分別命名為「Linux」與「Windows」。Linux下有一部名為「uBuntu_Server」的虛擬機器,Windows下則有一部「Vista_x86」虛擬機器。

Web_Access_11.png
(圖說)點選「uBuntu_Server」後,可以看到所有虛擬機器檔案。
請記得「storage1」這個儲存中心整個是使用VMFS3的檔案格式,ESX Server將.vmdk的虛擬磁碟儲存在這個中心下。

◎從樹狀目錄探討虛擬層的抽象化管理

Tree_0.tif
(圖說)如果沒有額外安裝VirtualCenter Server,並使用ESX Server本機當成Datastore,則圖中右上角的VI Client工具列上只有2個圖示。

Tree_1.tif
(圖說)如果獨立安裝VirtualCenter Server/Datastore,以及SAN儲存裝置,則VI Client工具列上會增加支援功能的按鈕(圖中右上角)。
圖中所要表現的是從VI Client看到虛擬機器時,中間所經過的基礎架構拓僕,在遠端管理介面上所看到的階層關係,則顯示在下圖中。
圖中未納入儲存裝置的抽象化示意圖(請看後續文章)。

Tree_2.tif
(圖說)圖中代表VI Client中樹狀目錄的示意圖,與上圖的實際架構比較,得知各階層的關係。最上層的「Hosts & Clusters」代表Resource Pool;次一階的「DataCenter_x」則是將Resource Pool切割而成的(請參考後續文章);再次一階的「ESX_Server_x」表示ESX Server叢集群中的單機伺服器;最後一階的「VM_x」則是ESX Server中的虛擬機器。
這些階層設定很彈性,可以依實際架構與管理員技能不同而修改,不一定與實際主機有著一對一的對應,真實的設定其實已經被抽象化。因此,設定後可以再更動,例如VM在各個ESX Server間遷移,ESX Server在各個DataCenter間遷移等,都只要滑鼠拖拉樹狀目錄的圖示就可以完成。隨意更動很容易混淆虛擬機器在各階之間的關係,所以文章開頭提到虛擬機器命名建議採用容易辨識的名稱,同理ESX Server與DataCenter也是。上圖只是舉例,但沒有特別命名。

Topology.png
(圖說)通常在備份時會需要釐清虛擬機器在拓樸中的位置,倘若還是分不清楚,工具列圖中可看到VI Client內建的「Maps」按鈕,軟體會自動繪出拓樸圖,而且可選擇拓樸關係:「Host to VM」、「Host to Network」、「Host to Datastore」、「VM to Network」、「VM to Datastore」。由於我手邊的硬體不足以安裝所有伺服器,僅能藉由公開資料解說。
圖片來源:「exchange_esg_validation_report.pdf」

Resource Pool.tif
(圖說)ESX Server中將伺服器運算資源以類似叢集的技術,統合成一個Resource Pool,再從中分割成數個運算單位(含處理器與記憶體),配置成DataCenter或虛擬機器群。圖中可以看到Resource Pool的CPU與Memory是所有ESX Server的總合。
Resource Pool可看成是一群伺服器主機的抽象化集合,虛擬機器不一定被限制在特定的ESX Server硬體中,每個DataCenter或每部虛擬機器運算資源是由ESX Server主機群所共同提供並切割而形成的。圖中尚未包括後端的儲存裝置,這部份解說請看下圖。

Datastore.tif
(圖說)圖中展現出虛擬磁碟(.vmdk)與儲存中心(Datastore)的關係,以及連接實體儲存裝置的整體架構。
從示意圖可以看到DataCenter(指虛擬機器群)與Datastore(指虛擬磁碟群)之間並非一對一的關係,這種關聯賦予DataCenter更多組合多部虛擬機器的彈性,使各部虛擬機器可以在多個DataCenter之間動態遷移;此外,VMFS3檔案系統則將實體儲存裝置抽象化,表示Datastore應用上不必了解後端到底是iSCSI SAN或FC SAN等硬體相異性,使Datastore可以在各種儲存裝置上彈性移動,包括內部的虛擬機器。
對照示意圖的解說,再回到文章中安裝虛擬機器的步驟,可以理解為何要先選擇虛擬磁碟儲存位置所在的Datastore,接下來才設定虛擬磁碟檔案與容量。

VMFS3.tif
(圖說)ESX Server的儲存架構比較複雜。虛擬磁碟(.vmdk)儲存在ESX Server專屬的VMFS3格式檔案中,而VMFS3對應到實體的儲存裝置前,還經過儲存虛擬化這個業界標準,形成2種不同的虛擬化介面與抽象化,在架構上是額外負擔。不過,其優點是虛擬機器、ESX Server或DataCenter可以彈性遷移,這是VMFS3檔案的提供的性能。

◎結論:文章所使用的範例只是最簡單的架構,在機房實作前則要仔細規畫,網友可以發覺不論是VMware ESX Server或Virtual Iron,所有硬體設備在虛擬化後都隱藏在Hypervisor這個虛擬層之下;硬體與軟體彼此間抽離後,基礎架構顯得非常抽象,與傳統伺服器服務與主機間一對一對應的管理方式顯著不同,而在資訊安全、備份、災難復原或性能調校等也採用虛擬化專屬的工具,對虛擬化新手管理員來說,得先學習如何跨過這個門檻。

我們很幸運地使用一般零售市場的個人電腦零組件,就可以安裝VMware ESX Server虛擬化軟體,在更早之前這是難以想像的事。不過,文章只是個開始,尚未談到虛擬化前如何規畫、ESX Server如何組成Resource Pool、以及伺服器如何平均地分配在各部ESX Server上,後續更重要的性能調校、偵錯與除錯等,這些都是虛擬化的關鍵之一。很可惜目前硬體不足以展示這些技術,或者網友能分享相關經驗。

至少我們已經有簡單的學習平臺,不必停留在看文章、憑空想像基礎架構虛擬化的模樣。接下來,除了官方網站的技術文件(白皮書實用性不高)、相關學術研究,建議網友參考作業系統書籍,以及Wiki英文網站上關於虛擬化的文章,特別是文末所列的參考資料等,我們在偵錯、除錯時會需要這些文件。

在這裡提醒網友,就目前來說,不是所有伺服器服務都適合x86虛擬化,因為許多技術還在發展與驗證中,這方面訊息建議參考Oracle官方網站的資料,其產品幾乎對x86虛擬化都是極大的挑戰(吃處理器與記憶體資源)。

◎補充:Microkernel的效率與安全性

VMware ESX Server使用自行開發的「vmkernerl」做為Hypervisor,負責處理器指令運算與記憶體管理等核心作業,也就是執行特權指令。
在作業系統分類上,vmkernerl是一種「microkernel」,可以看成是一種簡化的作業系統核心,也是許多虛擬化軟體常用來當成Hypervisor。接下來所要探討的是ESX Server採用microkernel的原因,同樣的理論也適用於採用microkernel做為Hypervisor的虛擬化軟體,例如XenServer、Virtual Iron等。

Microkernel.tif

一般作業系統核心區分為microkernel與monolithic kernel(請參考比較圖)。microkernel只包括處理器所需的執行緒管理(thread management)、記憶體管理與內行程通訊(Inter-process communication,IPC)等,真正作業系統所需的功能如驅動程式(Device Driver)或檔案管理(File Management)等,則由User-mode Servers提供相關服務,其IPC便是用於溝通這些服務。

一般常用的Linux、Windows則是hybrid kernel,混合microkernel與monolithic kernel兩種核心架構。作業系統所需的行程管理、記憶體管理、檔案管理與裝置驅動程式等都封裝在核心內,屬於Privileged-mode,只有應用程式屬於User-mode。

相對於monolithic kernel或hybrid kernel,microkernel較為穩定,當某一個提供服務的Server當機了,不至於造成核心也崩潰(crash),或影響其他Server的服務;而且核心僅包含最少的特權指令,所以相對地安全。不過,microkernel在效率上比monolithic/hybrid kernel略差,因為後者的特權指令都在核心內溝通(同一個kernel-mode),但microkernel卻透過IPC溝通,所以核心將會經過2次的mode switches,也就是user-mode→kernel-mode→user-mode,但mode switches需要context switch,造成較低的效率。(相關技術說明請參考作業系統教科書)

雖然XenServer、Virtual Iron、VMware ESX Server等這類產品常使用microkernel做為Hypervisor,主要也是穩定與安全考量大於效率。VMware ESX Server 3.0版開始,vmkernerl是由Linux Kernel中的「initrd」行程載入的,有時會誤以為ESX只採用Linux Kernel。這個Linux Kernel用來提供ESX Server管理所需的Service Console,與vmkernel用於執行特權指令是不同的。

3
(說明)這篇文章原本先發表在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。

4
這篇文章的PDF版本,放在下列網址:

Virtual Iron_4.2.pdf

請網友指教

5
◎標題:[軟體應用]軟、硬兼施下的虛擬化:Virtual Iron v4.2 Single Server Edition
◎前言:(提醒,文章內沒有效能測試,原因是使用個人電腦,而不是企業用主機)虛擬化目前看似軟體、硬體廠商在各彈各的調,雖然使用者應用VMware、VirtualBox、Virtual Server等軟體已經不陌生,但還難以明瞭(Full)Virtualization與Para-virtualization究竟有什麼差別,以及Intel VT-x/AMD Pacifica等硬體指令集效果到底如何。
虛擬化軟體供應商之一的Virtual Iron商業版率先讓VT-x/Pacifica支援Para-virtualization中的Hypervisor,在軟體、硬體雙管齊下,宣稱能使虛擬機器達到理論中提到的「Native VM」,只是在x86虛擬化尚未成熟之際,還需要市場考驗。無論如何,這是極待突破的里程碑,因為x86虛擬化一直在嘗試達到與真實主機相近(也就是Native)的運作效率和資源使用率,特別在x86架構並不適合用於虛擬化的難題下,僅依靠軟體的協助,只能做到Para-virtualization。直到VT-x/Pacifica硬體輔助指令,才從Para-virtualization進一步提升到Native VM,但這兩種技術在原理上是相似的,差別是後者加上硬體輔助指令。
有趣的是,Virtual Iron是根基於Xen而來的,範例所使用的Virtual Iron Single Server Edition在安裝過程甚至與Citrix XenServer相近,卻比Xen先宣佈Native VM的應用。
不過,Virtual Iron知名度並不如VMware、VirtualBox或Xen等來得高,藉此論壇簡單介紹安裝Virtual Iron的過程,以及相關的技術供網友參考。此外,Virtual Iron與XenServer在安裝過程中相似,已經有XenServer應用基礎用戶可以跳過這篇文章。

◎步驟:硬體配置(Virtual Iron Single Server Edition參考架構)
Virtual Iron Concept.tif
(圖說)從概念圖可以瞭解Virtual Iron屬於Para-virtualization,其Hypervisor具備類似Host OS的核心功能。
Virtual Iron Reference Architecture.tif
(圖說)實際部署的主機。因為是參考用,所以採用個人電腦與網路設備。請注意,伺服器端的硬碟資料會被格式化,安裝前應先備份資料。client端則沒有此顧慮。

請準備兩部主機。
一部做為Virtual Iron伺服器(稱為Managed Node),並安裝Virtual Iron Single Server Edition。在硬體上特殊需求要支援Intel VT-x/AMD Pacifica指令集主機。
另一部遠端管理主機(Virtualization Manager client),只要一般個人電腦或筆記型電腦,並安裝Windows XP以上的作業系統即可。
兩部主機透過10/100 Ethernet Switch連接,並設定內部網路IP、Netmask等。

◎步驟:安裝Virtual Iron v4.2 Single Server Edition
Virtual Iron官方網站下載Single Server Edition試用版,網址:
http://www.virtualiron.com/products/Free_Download.cfm
下載後是一個檔名類似「VirtualIronSingle4214.iso」影像檔,以燒錄軟體燒錄後就是一張安裝光碟。(請注意,安裝時會格式化儲存設備,建議應備份檔案)
安裝光碟放入Virtual Iron伺服器的光碟機中,系統會自動掃瞄硬體與儲存系統(如果沒有SAN/iSCSI,就會列出個人電腦上的硬碟)。如果硬體相容檢查沒發生問題,伺服器安裝過程自動化進行,只有在使用者帳戶與網路等處需要設定參數,其他都不用人工介入。
因為伺服器安裝自動化且沒有可著墨之處,也難以截圖,所以暫且略過。
最後會出現伺服器所在的IP的文字(文字模式介面,常使用Linux網友應不陌生),也就是範例中的「http://192.168.10.10」,表示安裝完成。

◎步驟:安裝Virtualization Manager client
改換到另一部個人電腦並以區域網路連接Virtual Iron伺服器後,在FireFox/IE瀏覽器網址欄位中鍵入伺服器所在的IP:http://192.168.10.10。連接無誤後會出現以下畫面:
Manager_1.tif
點選圖中的「Administration Manager」進入管理介面(加入試用版授權等)或「Virtualization Manager」進入虛擬機器管理與安裝。

Manager_2.tif
(圖說)點選「Virtualization Manager」後,出現安裝JNLP檔案的提示,因為管理介面是Java所寫的。這裡選擇「開啟方式」。
Manager_3.png
(圖說)使用者認證畫面,請輸入管理員帳號與密碼,也就是在安裝Virtual Iron伺服器時設定的管理員資料。
Manager_4.tif
(圖說)等待Virtualization Manager初始化,約1分鐘後出現圖中畫面。
畫面中紅框部份的樹狀結構,在企業應用的伺服器集中管理有其特別意義,與Citrix XenServer、VMware ESX Server等應用概念相似,但在單機上先不談論。
Manager_5.png
(圖說)如果選擇的是「Administration Manager」,輸入帳號與密碼後,便出現圖中的管理介面。前面步驟與「Virtualization Manager」相同。

◎步驟:設定虛擬儲存裝置
Virtual Iron在企業應用中,硬體資源是集合成Resource Center統一配置的,每一部伺服器則稱為節點(Managed Node)。這樣的應用情境下,為了不讓硬碟I/O形成運作瓶頸,儲存裝置通常是SAN、iSCSI等設備,所以在Virtual Iron中安裝虛擬機器之前,必須先指定虛擬磁碟位置與容量。這種步驟與VMware GSX Server/Workstation、VirtualBox等先設定虛擬機器,再決定虛擬磁碟的概念不同。

Manager_6.tif
(圖說)Virtual Iron中虛擬機器所使用的虛擬磁碟,來自於Disk Group下的Logical Disks,與VMware GSX Server/Workstation單機應用時的local disk不同。依據圖中說明即可。
Manager_7.tif
(圖說)Disk Group可隨意命名,例如Disk Group_uBuntu,或保持預設值也可以。
Manager_8.tif
(圖說)左側列出Virtual Iron所找到的儲存裝置,圖中是單機硬碟。請將此硬碟加入右側可配置磁碟的區域。
Manager_9.tif
(圖說)完成後如圖所示,但還沒結束。目前只設定虛擬磁碟所使用儲存裝置的位置,接下來要配置磁碟空間。
Manager_10.tif
(圖說)Local Disk可隨意命名,例如Logical Disk_uBuntu,或保持預設值。
Manager_11.tif
(圖說)完成後如圖所示,到這個步驟後才開始安裝虛擬機器。

◎步驟:安裝虛擬機器(在Virtual Iron稱虛擬機器為Virtual Server)
 Manager_12.tif
(圖說)滑鼠點選Virtual Server Node,也就是圖中名為「carejollg」圖示,可自行改名。
企業應用於伺服器集中管理時,命名建議採用有意義的單字,方便管理員理解虛擬機器的分類與資源。
因為虛擬化時會將後端主機與儲存裝置統一集中分配,在這個管理介面會變得很抽象,不容易體會虛擬機器在真實硬體位置,管理員要花一些時間習慣。後續備份或V2V遷移時才不至於混亂。
Manager_13.tif
(圖說)Virtual Server可隨意命名,建議與OS相關的單字,例如uBuntu_Server。或加上版本,例如多部Windwos Server,但不同Patch版。
Manager_14.png
(圖說)因為範例中MA78GM-S2H只找到一部SCSI硬碟,無法辨識SATA上的兩部WD硬碟,所以這裡僅顯示第一項。
Manager_15.png
(圖說)之前在這部磁碟機上設定Logical Disk,所以這裡也列出其名稱。
從命名可以快速理解uBuntu所在的虛擬機器位於哪一個Virtual Data Center→Virtual Server Node→Disk Group→Local Disks等階層關係。
不過這是抽象化的概念,真實的Node與Disk可能是由主機群與儲存池(Storage Pool)所混合組成的。
Manager_16.png
(圖說)設定虛擬網路,網路卡的Mac Address可指定。
Manager_17.tif
(圖說)選擇虛擬機器的OS種類。範例使用的uBuntu不在正式支援的名單,所以改選「Other Linux」。因為OS從光碟安裝,所以選擇使用Host主機的光碟機當開機碟。
Manager_18.png
(圖說)設定虛擬機器使用的處理器數量與記憶體容量。
「Processor cap」是處理器預先保留的capacity,與「Priority」都是用於伺服器集中時,動態調整處理器的資源。例如在主機群中預留相當於2顆處理器的資源,但虛擬機器只使用60%,待高負載時才提高到90%。優先權也是類似的概念。
在多部虛擬機器的情境下,可以讓低負載的伺服器將運算資源配給高負載伺服器使用,讓負載平衡。
在此範例僅用預設值,記憶體則提升到1GB。
Manager_19.tif
(圖說)虛擬機器設定完成,所有組態列在圖中右側區域。
接下來按下圖中的開機鈕後,請記得開啟虛擬機器的console視窗,如下圖所示。
Manager_20.png
(圖說)虛擬機器的console視窗,這是另外打開的視窗,與Virtualization Manager所在的瀏覽器不在同一個視窗。
Manager_21.tif
(圖說)虛擬機器安裝完成後,請記得將開機裝置改成虛擬磁碟開機,再按下圖中的開機按鈕。到此結束安裝過程簡介。

◎步驟:比較Virtual Iron與VMware GSX Server/Workstation管理介面

Manager_22.tif
(圖說)Virtual Iron透過Virtualization Manager介面,並以瀏覽器與遠端的伺服器連接和管理虛擬機器,並且開啟另一個console視窗。
Manager_23.png
(圖說)VMware GSX Server/Workstation則在單機介面完成管理與設定,使用同一視窗,但在ESX Server會與Virtual Iron相近。
習慣單機應用VMware單機版的用戶需要重新適應Virtual Iron的伺服器操作。

◎結論:x86虛擬化尚未成熟,更需要市場驗證
範例中並沒有測試Virtual Iron宣稱的Native VM與真實主機的效能差異,以及VT-x/Pacifica在Para-virtualization如何減少效能損耗等(因為使用個人電腦),只是用來簡介Virtual Iron。即使是可供驗證的環境,就不是一般企業可負擔的費用(例如刀鋒伺服器、GbE以上網路與FC SAN儲存裝置等),所以虛擬化的隱藏成本可能比未虛擬化前來得高。
況且,目前Intel/AMD處理器所提供的指令集僅只於處理器部份,與虛擬化相關的還有記憶體管理(Intel EPT/AMD NPT)、File Management(Intel/AMD IOMMU)等,以及資訊安全的控管與風險,等待新一代的平臺才支援。軟體供應商則需要再更新功能,以整合硬體技術,短期內x86虛擬化還未成熟。(HP/Fujitsu/Unisys/IBM等在大型主機的虛擬化與文章中的不同,除了成熟度高,也經歷市場驗證)
在真實的虛擬化應用情境中,伺服器集中管理是博大精深的一門學問,不僅技術難度高、風險也不小,絕不是在軟體中安裝虛擬化軟體,並啟動虛擬機器這麼簡單。僅是各虛擬機器的負載平衡與動態調配,就需要事前緊密地評估與測試,這方面各家產品都還沒有統一準則可遵循。
此外,範例中用於伺服器的GA MA78GM-S2H除了SATA硬碟無法正確辨識外,因而改用SCSI硬碟,安裝Virtual Iron可正常運作。這其實是運氣好,Para-virtualization不同於(Full)Virtualization具備Host OS,所以在硬體相容性較低(新版已改善許多),企業應用可能考慮原廠測試過的主機,以及調校至資源最佳化的狀態。
在遠端安裝uBuntu時,client的滑鼠反應有些遲鈍,可能是10/100 Ethernet Switch或儲存系統是單機硬碟造成效能瓶頸,或者是2者共同造成的。過去另一個安裝的範例選擇Citrix XenServer,但改用GbE Ethernet Switch與4顆SCSI硬碟所組成的Raid 0儲存系統,主機則是MSI的雙Xeon伺服器,便沒有滑鼠遲鈍的問題。
至於人們常用Benchmark測試Intel VT-x或AMD Pacifica等硬體輔助指令的效能,這裡並不做這類測試。由於範例中的主機本身就不是企業用途,所以不具測試上的意義。此外,虛擬化並非測試出漂亮的Benchmark數據,真實環境下的先導運作(pilot run)可以測試出Benchmark無法察覺的問題,例如在伺服器集中管理時,資源的動態調配以及虛擬機器如何部署、負載平衡等,則仰賴管理員的經驗。

頁: [1]