http://www.netadmin.com.tw/article_content.aspx?sn=1202130002&ns=1203280001&jump=3
Q4：啟用VMware HA功能後虛擬主機就不會有停機的狀況發生？
聽說啟用VMware HA功能之後，運作於其上的虛擬主機就不會因為實體主機損壞而產生停機（Downtime）的問題？
VMware HA（High Availability）的主要功能是，當實體伺服器發生不可預期錯誤而導致停機（也就是「非計畫性」的停機）時，原本運作在此台ESX/ESXi Host虛擬化平台上的虛擬主機（VM），會因為實體伺服器損壞而釋放對該虛擬主機及檔案（.vmdk）的鎖定機制（Locking），因此別台健康的ESX/ESXi Host便可以接手相關的虛擬主機及檔案。接手成功之後，便會將該虛擬主機「重新開機（Power On）」（圖7）。
▲圖7 實體伺服器故障時虛擬主機遷移至其他台ESX/ESXi Host上開機。圖片來源：VMware網站—High Availability（HA）
由此可以了解在VMware HA機制啟用後，當災難發生時，虛擬主機的停機時間（Downtime）將如下所示：
1. 實體伺服器損壞時，其上的虛擬主機等於不正常關機（斷電）。
2. 該台損壞的ESX/ESXi Host釋放虛擬主機檔案鎖定機制。
3. 虛擬主機在別台健康ESX/ESXi Host上開機。
Q5：若vCenter Server故障，則HA機制也無法運作？
|
因為建立VMware HA機制需要vCenter Server才能建立，所以當vCenter Server故障時，VMware HA也會無法運作嗎？
|
VMware vSphere 4.x中的HA機制是EMC收購Legato後，將該公司的Automated Availability Manager技術加以改進，然後改名為EMC Autostart。其運作原理是，加入HA Cluster中的前5台ESX/ESXi Host將成為Primary Host，而之後加入的Host則為Secondary Host，並且5台Primary Host會自動推舉一台成為Active Paimary Host（圖8）。
 |
| ▲圖8 VMware HA Cluster運作流程圖。圖片來源：VMware官方文件—High Availability and Data Protection |
Active Paimary Host功能的作用是，當ESX/ESXi Host發生故障損壞時，將會決定虛擬主機要在哪些健康的ESX/ESXi Host上進行啟動（若沒有特別指定啟動的Host時）。
而Primary Host的主要功能則為，同步整個HA Cluster之間所有Host的運作資訊，若故障損壞的ESX/ESXi Host是Primary Host時，則有其中一台Secondary Host遞補上來成為Primary Host。
VMware HA機制在建立時，確實需要由vCenter Server進行安裝Agent的動作，當ESX/ESXi Host加入至HA Cluster時，vCenter Server會在該ESX/ESXi Host上安裝「VMware HA Agent」。
此HA Agent為ESX/ESXi Host之間用來偵測彼此心跳（Heartbeat）以確認在同一個HA Cluster中的ESX/ESXi Host是否運作正常，因此當ESX/ESXi Host安裝好HA Agent後，即使vCenter Server故障，ESX/ESXi Host之間的HA Agent也能繼續偵測彼此心跳（Heartbeat），所以不會影響到VMware HA機制的運作。
至於最新版本VMware vSphere 5.0的HA機制，則已經不採用先前舊版的Primary/Secondary Roles，而改為採用Master/Slave Roles的運作概念。
也就是說，所有加入HA Cluster中的ESX/ESXi Host只有1台會成為Master Host，而其他主機則成為Slave Host，並且由Master Host來負責整個HA Cluster同步資訊，以及當有Host故障損壞時決定虛擬主機啟動於哪一台Host上。
至於成為Master Host的條件，則依照HA Cluster內所有的ESX/ESXi Host中，哪一台Host能連接存取到的「儲存資源Datastore」數量最多就成為Master Host，若大家能存取的數量都一樣時，則依MOID（Managed Object ID）數值進行比較，那一台MOID數值較大，便成為Master Host。 Q6：啟用VMware FT功能後，虛擬主機就不會發生停機狀況？
|
若希望虛擬主機不要有任何停機時間，則VMware FT機制是否能達成這個要求？
|
如果企業無法接受VMware HA機制啟動時虛擬主機有短暫的停機時間，則VMware FT可能是一個解決的方案，但是啟用VMware FT有許多先決條件，例如該虛擬主機不能進行快照（Snapshot）、無法使用Stoarge vMotion功能、該虛擬主機只能使用一個vCPU等等條件限制。
VMware FT機制會於2台不同的Host上分別建立Primary和Secondary虛擬主機，並且採用vLockstep技術以ESX/ESXi Host上的VMkernel Port來傳送Primary虛擬主機的資料至Secondary虛擬主機上，但是Secondary不會有實際I/O的寫入行為。
當Primary虛擬主機所處的ESX/ESXi Host故障損壞時，則Secondary虛擬主機會馬上接手相關作業，並且成為Primary虛擬主機，此時會在另一台ESX/ESXi Host上，再度建立一台新的Secondary虛擬主機來與Primary虛擬主機同步資料（圖9）。
 |
| ▲圖9 VMware Fault Tolerance運作流程圖。圖片來源：VMware官方文件—High Availability and Data Protection |
Q7：如何達成零停機（Zero Downtime）的目標？
|
若想以虛擬化平台來打造企業零停機（Zero Downtime）的環境應該如何達成？
|
經過上面相關的說明之後，可以將重點整理規納如下：
·vMotion/DRS：此機制適合用於「計畫性」停機，例如當ESX/ESXi Host實體伺服器發生記憶體、硬碟故障，或者需要停機進行韌體（Firmware）更新及歲修時，這種排定好的計畫性工作可以使用此技術，將運作於虛擬化平台上的虛擬主機，遷移到其他台ESX/ESXi Host上，讓企業可在服務不中斷的情況下維修實體主機。
·HA/FT：此機制為適合用於「非計畫性」停機。當ESX/ESXi Host實體伺服器電力系統出問題而不當斷電，或者實體主機的主機板損壞導致實體主機故障而這些非人為因素損壞之非計畫性故障狀況發生時，透過此機制可以使虛擬主機自動遷移到其他台ESX/ESXi Host上繼續開機運作。
但很重要的一點是，這些機制都僅僅是保護ESX/ESXi Host Level層級而已，而並非虛擬主機的作業系統層級（OS Level），以及作業系統上的應用程式層級（Application Level）。
例如先前提到的VMware HA機制，當ESX/ESXi Host故障損壞時，等於運作於其上的虛擬主機也是被不當關機，雖然虛擬主機可以在其他台Host上再度開機，但很有可能虛擬主機的作業系統已經因為不當關機而造成作業系統損壞，因此即使已經遷移到別台Host上，也無法順利開機成功，所以作業系統的備份作業有其必要性。
而VMware FT機制是讓2台虛擬主機資料一模一樣進行運作，因此若是Primary虛擬主機發生當機的狀況時，例如Windows作業系統發生藍色當機畫面（Blue Screen Of Death，BSOD），此時將會因為vLockstep同步機制，而使得Secondary虛擬主機也發生系統當機的狀況。
至於應用程式層級的保護機制，目前也有許多廠商研發相關機制，例如Symantec以Veritas Cluster技術開發的Application HA，便是可以保護虛擬主機上運作的應用程式，如MSSQL、Exchange、Oracle、SAP等等。
綜合上述說明之後可以了解到，想要達成企業服務零停機的目標，其實要努力的方向很多，從實體伺服器擺放機房的冷氣空調、電力迴路、網路設備至保護實體伺服器ESX/ESXi Host及運作其上的作業系統（OS）和應用程式（Application），都有許許多多不同的各種解決方案。
每種解決方案都有其優缺點存在，端看企業所能忍受的停機時間及預算，再預先做打算。Q1：vMotion/DRS需要vDS交換器才可建置？
|
聽說需要建立分佈式交換器vDS（vNetwork Distributed Switch）之後，才可以建置出vMotion/DRS遷移環境？這是真的嗎？
|
VMware虛擬化平台架構中包含兩種虛擬交換器，分別為適用於中小型網路環境的標準型交換器vSS（vNetwork Standard Switch）（圖1）以及適用於大型集中控制網路環境的分佈式交換器vDS（vNetwork Distributed Switch）（圖2）。
簡單來說，vSS交換器無法跨Host使用，而vDS不但可以跨Host使用，且當虛擬主機透過vMotion機制遷移到別台Host時，該虛擬主機在原先虛擬交換器中的相關設定，如流入（Inbound）和流出（Outbound）頻寬限制、虛擬網路VLANs設定等等，都會自動套用到新的虛擬交換器上。
虛擬交換器提供虛擬主機與實體網路交換資訊的能力，可以把ESX/ESXi Host上的實體網路卡（VMware稱為Uplink Port）指定給虛擬交換器，以達到負載平衡（Balances Traffic）和容錯（Failover）的功能（也就是NIC Teaming）。倘若虛擬交換器沒有指定實體網路卡，則表示此虛擬交換器只能用於虛擬主機之間進行資料交換，無法與實體網路環境溝通。
 |
| ▲圖1 標準型交換器vSS（vNetwork Standard Switch）。圖片來源：VMware官方文件—ESXi Configuration Guide |
 |
| ▲圖2 分佈式交換器vDS（vNetwork Distributed Switch）。圖片來源：VMware官方文件—ESXi Configuration Guide |
但是否就表示一定要vDS才能建置進階功能vMotion/DRS遷移環境呢？答案當然是否定的。就vSphere ESXi軟體授權來說，必須購買最高等級授權Enterprise Plus才具備分佈式交換器功能，而其他授權版本若想建立支援vMotion/DRS遷移的環境，則利用vSS虛擬交換器即可建置。
不過前提是，ESXi Host主機之間的vSS虛擬交換器必須「Port Group名稱相同」，才可進行vMotion/DRS，將虛擬主機遷移到另一台Host上相同的虛擬交換器。
但是，相關設定並不會隨著遷移過去，所以遷移後必須檢查相關設定，以避免遷移後虛擬主機網路不通的情況發生，當然還要符合如網路資源共通、儲存資源共享等等的其他運作條件。
以下為虛擬交換器vSS和vDS相關功能支援程度列表，讓讀者導入時可視需求及功能進行相關建置與設定：
 |
Q2：虛擬主機能否套用Microsoft Hyper-V虛擬機授權？
|
我已購買了Microsoft Windows Server 2008 R2 Enterprise在Hyper-V可運作的四個Windows授權虛擬主機，在VMware虛擬化平台上是否也可以使用這樣的虛擬主機授權方式？
|
沒問題！不管使用的是哪一種虛擬化產品，包括Microsoft Hyper-V、VMware vSphere ESX/ESXi、Citrix XenServer、Red Hat KVM等等，所購買的Microsoft軟體授權均適用。但是，Microsoft對於運作在非Microsoft軟體虛擬化技術上的虛擬主機並沒有提供技術支援。
所購買的軟體授權具有向下相容的降級權利特性，可執行舊版的Windows Server作業系統，舉例來說，若購買的是Windows Server 2008 R2 Enterprise軟體授權，則可以在虛擬主機上運作Windows NT Server 4.0/2000 Server/Server 2003/Server 2003 R2舊版作業系統，以及較低階的Server 2008 R2 Standard版本。
下列表格中整理了Windows Server 2008 R2各種版本的相關技術支援程度，以及在虛擬環境中常見的功能，例如虛擬機使用權利數量（Virtuall Image Use Rights）、叢集技術節點（Failover Cluster Nodes）、記憶體容錯同步（Fault Tolerant Memory Sync）、線上新增CPU及記憶體（Hot Add Processors、Memory）等等。
 |
當採購一份Windows Server 2008 R2 Enterprise軟體授權之後，每一份軟體授權允許在「一台實體伺服器」上運作1個實體OSE（Operating System Environment）及4個虛擬OSE，簡言之，就是可以運作1台Windows作業系統在實體主機上。但是只能提供硬體虛擬化服務或虛擬化管理軟體之用，以及在虛擬主機上運作4台Windows作業系統。
如圖3所示，一台實體伺服器購買Windows Server 2008 R2 Enterprise軟體授權，實體主機運作Hyper-V以進行硬體虛擬化（1 Physical OSE），並且在其上執行一套Windows Server 2003 R2、一套Windows Server 2008 R2 Standard、兩套Windows Server 2008 R2 Enterprise（4 Virtual OSEs）。
 |
| ▲圖3 Windows Server 2008 R2 Enterprise允許在實體伺服器上運作最多5台OSE。圖片來源：Microsoft Volume Licensing Brief: Licensing Microsoft Server Products in Virtual Environments |
若是在2台實體伺服器的情況下，能否將4台虛擬主機分散成在2台實體伺服器下運作呢？答案是可以，但必須符合下列兩個前提條件才行：
1. 另外一台實體伺服器也必須取得Windows Server 2008 R2 Enterprise或DataCenter版本軟體授權。
2. 另外一台實體伺服器上運作的虛擬主機不可大於本來的授權數量（Enterprise為4台虛擬主機，DataCenter則無限制）。
Q3：vCenter重新啟動後，為何vSphere Client無法連上？
|
vCenter主機為Windows作業系統，進行安全性更新之後重新啟動，但重新啟動後，vSphere Client卻無法連上vCenter Server，請問原因為何？
|
會發生這種狀況通常是因為將vCenter Database與vCenter Server安裝在同一台主機。導致此狀況的主因為，vCenter主機重新啟動時，vCenter Database的服務（例如MSSQL或MSSQL Express）尚在初始化期間。
由於vCenter Server的服務（VirtualCenter Management Webservice）已經要啟動了，但是vCenter Database尚未初始化完成，導致vCenter Server的服務啟動失敗。
所以，若遠端桌面連線至vCenter主機查看服務清單，就會發現vCenter Server的主要兩個服務VMware VirtualCenter Management Webservice及VMware VirtualCenter Server處於未啟動的狀態。
可以每次重新啟動vCenter Server主機後，再遠端登入，手動啟動這兩個服務，如此vSphere Client就可順利登入vCenter Server。可是這樣做總是有點麻煩，以下說明解決此問題的根本辦法。
根本的解決辦法是，將vCenter Database服務與vCenter Server服務進行相依性設定，簡單地說，就是日後vCenter Server重新啟動時，會先等到vCenter Database服務啟動完成之後，才接著啟動vCenter Server服務。
舉例來說，在下列設定環境中，vCenter Server為Windows Server 2003 R2，而vCenter Database是MSSQL Server 2005 Express。
首先登入至vCenter Server，點選「開始」功能表後點擊【執行】選項，接著輸入「services.msc」，開啟系統服務頁面。
隨後，確定vCenter Database的完整服務名稱，例如此例中MSSQL Server 2005 Express其服務的顯示名稱為SQL Server（SQLEXP_VIM），但完整服務名稱則是「MSSQL$SQLEXP_VIM」（圖4）。
 |
| ▲圖4 查看vCenter Database的完整服務名稱。 |
Q1：x86虛擬化技術該使用哪種才好？
|
常常聽到半／全虛擬化技術、CPU硬體輔助虛擬化，到底虛擬化技術應該採用哪一種方案比較好？
|
在說明x86虛擬化技術之前，應該先從x86架構CPU特權模式（CPU Privileged Mode）談起，由於x86架構一開始設計架構是以「個人電腦」為定位，因此要做到硬體資源虛擬化有很大的困難。
 |
| ▲圖1 在保護模式下x86架構可用的權限（Privilege rings for the x86 available in protected mode）。圖片來源：維基百科—Ring（Computer Security） |
從如圖1的x86CPU特權模式中可以看出，在CPU運作架構上共有從Ring 0∼Ring 3四個特權等級。
其中，權限最高為Ring 0，通常為作業系統，它可以與核心（Kernel）溝通，直接控制實體主機硬體資源的使用，如CPU、Memory和Device I/O。而Ring 1和Ring 2很少使用到，通常為周邊裝置的驅動程式。最後，使用者端所碰觸的應用程式則是處於Ring 3特權模式。
虛擬化技術則是在CPU架構中插入Hypervisor來管理硬體資源，Hypervisor為一介於軟體與韌體中一層極小的程式碼，可以提供動態的硬體資源配置及彈性設定和管理虛擬資源，並且由VMM（Virtual Machine Monitor）來取代本來由作業系統所掌管的Ring 0特權模式，而原來的作業系統則降一級成為Ring 1。
但是，某些作業系統中的指令必須在Ring 0特權模式才可正常執行，因此便衍生出半／全虛擬化技術（Para/Full Virtualization），Intel稱之為Software-only Virtualization，來解決特殊指令無法順利執行的問題。
半虛擬化技術（Para Virtualization）
因為必須修改作業系統核心而植入Hypercall，使得作業系統不必為了虛擬化而將CPU特權等級被調降到Ring 1（保持在Ring 0），並且透過Hypercall來存取硬體資源。
優點：此方式虛擬化對於硬體資源消耗相對較少。
缺點：因為必須修改作業系統核心，因此可於半虛擬化平台上運作的作業系統種類較少。
全虛擬化技術（Full Virtualization）
以VMware技術來說，為採用二進位轉譯（Binary Translation）技術，在因為虛擬化而降級的作業系統（Ring 1特權模式）存取硬體資源時，會由VMM將作業系統發出的CPU指令透過二進位轉譯技術進行轉換，進而順利存取硬體資源。簡言之，作業系統並不知道自己被調降到Ring 1特權模式中。（圖2）
 |
| 圖2 純軟體虛擬化技術（Software-Only Virtualization）。圖片來源：Intel Virtualization Technology – Processor Virtualization |
優點：不需要修改作業系統核心，因此可運作大部分的作業系統種類。
缺點：透過二進位轉譯會消耗較多的硬體資源。
CPU硬體輔助虛擬化（Hardware Assisted Virtualization）
因為軟體架構虛擬化的技術各有其優缺點，因此CPU大廠Intel和AMD決定從x86 CPU架構著手來改善x86虛擬化的門檻，分別提出了Intel-VT（Vanderpool）（圖3∼4）以及AMD-V（Pacifica）虛擬化技術。
 |
| 圖3 Intel虛擬化技術的演進。圖片來源：Intel Virtualization Technology – Processor Virtualization |
 |
| ▲圖4 採用Intel VT-x虛擬技術前後架構上的改變。圖片來源：Intel Virtualization Technology – Processor Virtualization |
簡單來說，該技術是將原有的CPU特權模式分為兩個等級，原先的Ring 0∼Ring 3稱為Non-Root Mode，新增的Ring -1則稱為Root Mode。
如此一來，VMM便使用Ring -1，而作業系統則維持原來的Ring 0，因此使用CPU硬體輔助虛擬化之後，半虛擬化技術不需要事先修改作業系統核心來符合運作架構，而全虛擬化技術也不用做二進位轉譯。並且，採用CPU硬體輔助虛擬化之後，兩者不論在運作效能或硬體資源消耗上其實都相差無幾。
Q2：啟用HT功能後，核心數量多一倍，所以運作效能更好？
|
開啟主機上的HT（Hyper Threading）技術後核心數量會多一倍，因此運作效能一定表現更好？
|
虛擬主機（Virtual Machine，VM）的CPU稱之為vCPU，當虛擬主機需要CPU運算資源的時候，VMkernel會將此虛擬主機需要的運算資源對應（Mapping）到實體伺服器的CPU核心運算HEC（Hardware Execution Context）能力，以使得虛擬主機得以進行運算。簡單來說，HEC就是實體伺服器的CPU核心數（Cores）。
所以，如圖5所示當虛擬主機配有1 vCPU，在需要運算資源時，只要VMkernel對應到實體主機上其中一個HEC就可以執行運算；若虛擬主機配有2 vCPU，在需要運算資源時，則必須對應到2個HEC才能運算；若4 vCPU則要對應4個HEC才能運算。
 |
| ▲圖5 虛擬主機vCPU與實體伺服器HEC對應。圖片來源：VMware Communities - Recursos para cluster HA |
因此，虛擬主機上配置的vCPU數量愈多，雖然可以達成平行運作的優點，但相對地，實體主機上的核心數也要能夠同時對應才行。
當實體伺服器開啟HT功能之後，一個實體CPU核心將具有兩個邏輯處理單元。如圖6所示，可以看到當2 CPU Socket、2 CPU Cores的實體伺服器開啟HT功能之後，核心運算能力HEC即從4個提升為8個。
 |
| ▲圖6 實體伺服器開啟HT功能後vCPU與HEC的對應。圖片來源：VMware Communities - Recursos para cluster HA |
但眾所周知的是，開啟HT功能後的邏輯處理單元必須在作業系統及應用程式支援的前提下才能提高運算效能（提升約1.2∼1.5倍），倘若在不支援的情況下，運算效能反而比本來還低。
雖然，VMkernel在對應vCPU至HEC運算能力時會盡量不對應到同一個實體核心（Core）上，但是當系統忙碌時且虛擬主機須一次對應多個vCPU時，就可能發生對應到同一個Cores上邏輯的HEC，而造成vCPU雖然已對應到HEC但還是沒有實際運算能力，因此建議關閉實體伺服器的HT功能。 Q3：採用e1000網卡，還是vmxnet 3網卡？
|
虛擬主機應該要採用Intel e1000網卡，還是VMware第三代vmxnet3網卡？在網路封包吞吐量上哪一種比較好？
|
E1000網卡為模擬Intel e1000的網卡驅動程式，通常虛擬主機在未安裝VMware Tools情況時才會採用此網卡，因此建議為虛擬主機安裝VMware Tools，並採用VMware第三代vmxnet3網卡。
以下表格列出了E1000網卡及vmxnet3在進階網路功能上的支援程度。
E1000網卡和vmxnet3網卡網路功能比較
 |
事實上，安裝好虛擬主機後，應該要先安裝VMware Tools，因為可以使用vmxnet3及進階網路功能。許多人對於VMware Tools的某些功能有所誤解，常常認為安裝VMware Tools不過就是讓虛擬主機的滑鼠不會被咬住，或者只是使虛擬主機與虛擬化平台進行時間校對而已，這樣想的話，就太小看VMware Tools的功用了。
當虛擬主機安裝VMware Tools之後會提供許多進階功能，使得虛擬化平台在調校硬體資源給虛擬主機時能夠更緊密的結合，以下列舉部分VMware Tools所提供的進階功能：
·虛擬裝置驅動（Device Drivers）：提供給虛擬主機周邊裝置最佳化後的驅動程式，如SVGA Display Driver。
·虛擬主機心跳偵測（Virtual Machine Heartbeat）：若有導入VMware HA進階功能，vCenter Server就是藉由VMware Tools來偵測虛擬主機的心跳（Heartbeat）是否正確運作，以便判斷是否該將虛擬主機移轉至別台ESX/ESXi Host。
·提升滑鼠效能（Improved Mouse）：在VM Console操作虛擬主機時，滑鼠移動時很順暢，不會反應遲鈍，並且毋須從VM Console中使用組合鍵手動釋放滑鼠指標。
·記憶體管理（Memory Management）：ESX/ESXi Host對於運作於其上的虛擬主機進行記憶體管理機制，例如Memory Ballooning機制的觸發也須透過VMware Tools來進行，以便實體機Host記憶體不足時，虛擬主機能夠依靠Memory Ballooning機制自行建立Page File或SWAP，撐過硬體資源不足的過渡期。
·檔案系統暫停（Quiescing a Guest File System）：ESX/ESXi Host藉由此機制來為虛擬主機建立快照（Snapshot）。
·時間同步校對（Time Synchronization）：可以直接讓虛擬主機與ESX/ESXi Host進行系統時間同步校對，若虛擬主機為Windows網域成員並會與Windows AD伺服器進行同步校對的話，則建議選擇其一。
·正常關機（Gracefully Shutdown）：當按下VM Console的關機按鈕（紅色四方形圖示）時，則虛擬主機會執行正常程序進行關機。Q4：ESXi是免費版，所以無法使用進階功能？
|
聽說vSphere ESXi是免費版，所以無法使用Linux相關指令以及運作vMotion、DRS、HA、FT等進階功能？
|
在VMware vSphere 4.x中分成ESX和ESXi兩種版本，而虛擬化平台的進階功能是採用以軟體授權序號的方式來進行決定，舉例來說，在vSphere 4.0版本中若想具有HA進階功能，則至少必須使用Essentials Plus授權才行，若是需要大量部署虛擬化平台的設定Host Profiles，則必須使用Enterprise Plus授權。
輸入軟體授權序號後，在vSphere Client的〔Configuration〕活頁標籤內，從Software區塊的「Licensed Features」項目中，便可以看到此序號所具備的特色功能列表「Product Features」，因此可以得知ESX/ESXi Host進階功能是由「軟體授權序號」來決定，而非採用ESX或ESXi平台來決定。圖7為vSphere ESXi 4.1採用免費授權序號後的功能列表。
 |
| ▲圖7 VMware vSphere ESXi 4.1免費版本授權資訊。 |
那麼該選擇ESX還是ESXi虛擬化平台呢？在ESX平台架構（圖8）中有一個虛擬化核心被稱為COS（Service Console），使用者登入COS後可以對ESX虛擬化平台進行相關操作及管理，而VMware Agent也安裝於COS中。
 |
| ▲ 圖8 VMware ESX 虛擬化平台架構。圖片來源：VMware官方網站–VMware ESXi and ESX Info Center |
COS是基於Red Hat企業版RHEL（Kernel 2.6.x/RHEL 5.2）所開發改寫而成，所以許多在Linux作業系統中可以執行的指令，在ESX平台中也能夠執行。
但是，它畢竟是一個作業系統，因此也會占用及消耗ESX Host較多的硬體資源，並且也要為Linux作業系統進行相關的安全性更新。
ESXi架構（圖9）中移除了COS（Linux作業系統），所有的VMware Agent直接運作在VMkernel之上。由於將COS移除，因此ESXi Host的硬體資源將更為豐富，同時因為不需要為Linux作業系統進行安全性更新，連帶地使得ESXi Host平台架構的整體安全性更高。
 |
| ▲圖9 VMware ESXi虛擬化平台架構。圖片來源：VMware官方網站—VMware ESXi and ESX Info Center |
並且，只有通過驗證的第三方軟體套件模組（Third Party Modules）才可安裝至ESXi Host中，也使得ESXi Host穩定性更加提升。但也因為此平台移除了COS，所以一般認知中的Linux指令大多無法執行，因而造成許多使用者誤以為ESXi是免費版的關係所致。
事實上，VMware官方於VMware vSphere 4.1發布時便說明，此為最後一版具有ESX平台架構的版本，因此在最新發布的VMware vSphere 5.0版本中，可以看到只有ESXi平台架構的版本，而沒有ESX平台的版本。
那麼該如何找到免費版虛擬化平台的相關資訊？有鑑於大多數使用者誤以為ESXi就是免費版，因此從VMware vSphere 4.1版本開始，VMware官方將免費版的虛擬化平台稱之為「VMware vSphere Hypervisor」，表示此平台只有Hypervisor是免費且不具備任何進階功能，同時免費版本也無法被vCenter Server所納管，但可以使用vSphere Client進行單台管理。
若希望同時管理多台免費版本VMware vSphere Hypervisor，可以嘗試使用免費的網頁管理平台「VMware Go」進行管理。
下表為針對ESX 4.1、ESXi 4.1、ESXi 5.0相關功能性進行比較。
 |
Q5：虛擬主機是否需要磁碟重組？
|
Windows作業系統為實體機器時，常常需要進行磁碟重組以加快磁碟I/O的存取速度，那麼虛擬主機需要嗎？
|
VMware採用的檔案系統為VMFS（Virtual Machine File System），如圖10所示，此檔案系統最大的兩項特色如下：
1.叢集檔案系統（Cluster File System）
在同一個儲存資源LUN（VMFS Volume）上，允許多台ESX/ESXi Host同時進行資料存取（讀取及寫入），類似於平行寫入的機制，因此選擇採用儲存設備之前，須先確認支援Multi-Thread而非Single-Thread，否則運作時會發生問題。
2.磁碟鎖定（On-Disk Locking）
雖然檔案系統可以允許多台Host同時存取，但每台虛擬主機同一時間只能被一台Host所控制，除非已啟動vMotion或HA機制，它會在啟動機制時解除虛擬主機磁碟檔案被鎖定的狀態。
 |
| ▲圖10 虛擬主機檔案（黃色）、虛擬主機檔案系統（綠色）、vmdk虛擬檔案（紅色）、VMFS檔案系統（藍色）一覽表。圖片來源：VMware官方網站–VMware Fusion Blog Defragmentation |
磁碟碎片（Disk Fragmentation）的產生原因是，資料寫入時並非為連續狀態，因此造成讀取時必須增加磁碟轉速來尋找這些不連續的資料，而VMFS檔案系統不會發生這樣的問題，其主要原因如下：
1. VMFS的區塊空間（Block Size）通常是連續且占用大空間，即使是不連續的區塊空間通常也相隔不遠，因此對於Disk I/O Request的動作影響不大，因此效能不會受到影響。
2. 虛擬主機檔案（Virtual Disks）通常是個非常大的單一檔案，如ESXi 5.0預設採用Thick Provisioned Virtual Disks，不像實體機器是許多零散檔案的集合，因而造成讀寫延遲（I/O Latency）的狀況，導致效能受到影響。
3. 當採用的是實體機的本機磁碟，或許還會看到些許的磁碟碎片，若採用的是SAN儲存設備，則因為磁碟陣列通常具有讀寫快取機制（I/O Cache）機制，因此幾乎不會有磁碟碎片產生。
4. 若採用的是Thin Provisioned格式，也不必擔心產生磁碟碎片，因為通常安裝好的相關檔案有許多檔案內容是不常變動的，稱為冷區塊（Cold Block）。若同類型的虛擬主機愈多時會共用這個冷區塊，而後續資料變動後所產生的資料，則稱為熱區塊（Hot Block）。
Q6：VMware Data Recovery能否備份虛擬主機？
|
是否可以使用VMware內建的備份工具Data Recovery（vDR）來備份所有虛擬主機？而且不管作業系統是Windows、Linux或其他種類？
|
VMware Data Recovery（vDR）是VMware官方以vStorage API規範所開發出來專為中小型企業使用的基本備份虛擬主機工具（圖11），屬於Disk-based的備份方式，具有簡單操作及容易部署的特性（因為它也是一台虛擬主機），支援Windows VSS（Volume Shadow Copy）備份方式，也支援簡單的重複資料刪除功能（Data De-duplication）。但是此備份工具有如下的相關功能限制：
·備份環境中必須具備vCenter Server，才可使用此備份工具。
·屬於Disk-based，因此無法使用File Level或Block Level備份方式。
·每台vDR僅能備份100台虛擬主機。
·無法運作於IPv6網路環境上。
·僅支援備份運作Windows作業系統（Windows 2000/XP/Vista/7、Windows Server 2003/2008）的虛擬主機，不支援其他作業系統，如Linux、Solaris等虛擬主機。
 |
| ▲圖11 VMware Data Recovery備份還原流程圖。圖片來源：VMware官方網站—VMware Data Recovery |