本文將實作示範讓大家瞭解到，當企業和組織的管理人員在Hyper-V虛擬化基礎架構中需要實作Nested VM巢狀式虛擬化環境時，只要滿足運作環境需求及相關限制時，便能順利建構出Hyper-V巢狀式虛擬化環境，而且即便使用Azure公有雲環境也不受限制。
關於Hyper-V「巢狀式虛擬化」（Nested Virtualization）技術，就是在Hyper-V VM虛擬主機環境中能夠再啟用並執行Hyper-V虛擬化技術。
過去，巢狀式虛擬化技術通常被用於測試和研發用途居多，例如在VM虛擬主機中執行Visual Studio手機模擬器，然而在容器風潮的世代下，透過整合巢狀式虛擬化的「Hyper-V容器」（Hyper-V Container）技術，則能夠真正應用於正式營運環境，並進一步隔離及確保容器安全性。
在未支援或啟用Hyper-V巢狀式虛擬化的運作環境中，處於底層Level 0的Hyper-V Hypervisor虛擬化管理程序將會完全掌管「虛擬化擴充功能」（Virtualization Extensions），並且Hyper-V Hypervisor虛擬化管理程序不會將底層硬體輔助虛擬化功能（例如Intel VT-x或AMD-V）傳遞給上層Level 1運作的VM虛擬主機客體作業系統，如圖1所示。
圖1 未支援或啟用Hyper-V巢狀式虛擬化的運作環境架構示意圖。 （圖片來源：什麼是Hyper-V的巢狀虛擬化？| Microsoft Learn）
現在只要採用的硬體架構支援虛擬化技術，並且採用Windows Server 2016、2019、2022、2025伺服器作業系統，以及Windows 10、11客戶端作業系統，如圖2所示，便能啟用Hyper-V巢狀式虛擬化技術，並且Hyper-V Hypervisor虛擬化管理程序可以順利地將底層硬體輔助虛擬化技術，傳遞給Hyper-V虛擬化平台上層運作的VM虛擬主機使用。
圖2 Windows 10及11安裝Hyper-V虛擬化技術示意圖。 （圖片來源：安裝Hyper-V | Microsoft Learn）
舉例來說，當採用的硬體支援硬體輔助虛擬化技術，安裝Windows Server 2025雲端作業系統，處於Level 0並啟用Hyper-V虛擬化功能後建立VM虛擬主機，在啟用巢狀式虛擬化技術後，處於Level1的VM虛擬主機也能啟用Hyper-V虛擬化功能，建立Level 2層級的VM虛擬主機，達成VM虛擬主機中再建立VM虛擬主機的巢狀式虛擬化運作架構，如圖3所示。
圖3 啟用Hyper-V巢狀式虛擬化的運作環境架構示意圖。 （圖片來源：什麼是Hyper-V的巢狀虛擬化？| Microsoft Learn）
運作環境需求及相關限制
在開始實作Hyper-V巢狀式虛擬化之前，先了解運作環境需求以及相關限制，避免後續實作時發生不可預期的錯誤。
首先，在x86實體伺服器的CPU處理器選擇方面，應該選擇「高時脈」以便獲得更高效能的運算速度？或是選擇「多運算核心」達到平行運算的目的？
管理人員應該考量的重點在於，依屆時運作於Hyper-V虛擬化平台上，大部分VM虛擬主機的作業系統和應用程式工作負載類型而定。舉例來說，當VM虛擬主機的應用程式工作負載屬於「單線程」（Single-Thread）類型時，便應該選擇採用「高時脈」類型的CPU處理器較為適合，因為這類型的應用程式即便為VM虛擬主機配置多個vCPU虛擬處理器，由於應用程式的單線程特性，也只能使用單一vCPU虛擬處理器進行運算，所以配置高時脈的CPU處理器才能正確地選擇。一般來說，企業和組織如果部署的Hyper-V主機叢集為VDI遠端桌面應用時，便適合採購高時脈的CPU處理器。
那麼當VM虛擬主機中的應用程式工作負載為「多線程」（Multi-Thread）類型時，就應該選擇「多核心」類型的CPU處理器，這時為VM虛擬主機配置多個vCPU虛擬處理器才有意義，因為應用程式的多線程特性，可以使用VM虛擬主機的多個vCPU虛擬處理器運算資源，執行平行運算的目的，所以高時脈便不是考量的重點，而是有越多的實體運算核心才是正確的。一般來說，部署的Hyper-V主機叢集，為企業和組織各種伺服器應用時，或營運服務的應用程式具備多線程特性的時候，便適合採購高時脈的CPU處理器。
至於與作業系統版本搭配方面，當採用Intel處理器且支援VT-x和EPT硬體輔助虛擬化技術時，使用Windows Server 2016（或更新版本）、Windows 10（Pro或Enterprise）或更新版本，並且至少搭配VM虛擬主機組態「8.0」或更新版本，便能實作Hyper-V巢狀式虛擬化。
倘若採用的是AMD EPYC或Ryzen處理器硬體輔助虛擬化技術時，則必須使用Windows Server 2022或更新版本，使用Windows 11（Pro或Enterprise）或更新版本，並且至少搭配VM虛擬主機組態「9.3」或更新版本，才能實作Hyper-V巢狀式虛擬化。
在Hyper-V伺服器的實體記憶體方面，原則上當然是越多越好。主要原因在於，現代化的應用程式其工作負載越來越大，各類作業系統的運算資源最低需求也不斷提升。此外，Hyper-V虛擬化環境雖然支援記憶體資源超額使用機制，亦是如此。
然而，一旦過度超用記憶體資源時，當Hyper-V實體伺服器記憶體空間不足，便會迫使Windows Server作業系統透過儲存資源空間產生分頁檔案，以便嘗試過渡記憶體空間不足的情況，簡單來說，這將會直接影響並降低Hyper-V虛擬化平台的運作效能。
原則上，建議為正式營運的Hyper-V伺服器提供足夠甚至更多的記憶體資源。如果企業或組織礙於IT預算的關係而無法採購足夠的實體記憶體時，建議應該依照下列準則來優化分頁檔案的運作效率：
‧應該將分頁檔案指定產生在與Hyper-V運作隔離的儲存資源環境，也就是不要與Windows Server作業系統，或是應用程式工作負載採用同一個儲存資源。
‧雖然將分頁檔案指派在SSD固態硬碟，可以在Hyper-V虛擬化使用到分頁檔案時，讓效能表現不致降低太多，然而若存放分頁檔案的SSD固態硬碟發生故障，則系統可能會發生BSOD系統崩潰的情況產生。
‧分頁檔案要採用隔離原則，不要將多個分頁檔案同時產生在同一個儲存資源內。
原則上，在硬體伺服器或實體主機的部分，只要支援硬體輔助虛擬化技術，搭配上述符合版本需求的Windows作業系統，便能實作Hyper-V巢狀式虛擬化。如果還是發生無法順利實作的情況，可以在主機中開啟命令提示字元，使用「systeminfo.exe」指令，確認是否符合Hyper-V虛擬化運作環境需求，如圖4所示。 上述是在企業或組織中，地端資料中心實作Hyper-V巢狀式虛擬化的部分。倘若管理人員希望在Azure公有雲環境實作時，於建立Azure VM虛擬主機流程中，在Security type部分必須選擇「Standard」（預設值為Trusted launch virtual machines），在VM虛擬主機Size部分則必須選擇D系列和E系列，才能順利實作Hyper-V巢狀式虛擬化，如圖5所示。
圖4 確認硬體伺服器或實體主機是否正確支援硬體輔助虛擬化技術。 （圖片來源：System requirements for Hyper-V on Windows and Windows Server | Microsoft Learn）
圖5 Azure VM虛擬主機實作Hyper-V巢狀式虛擬化注意事項。
Level 0安裝Hyper-V虛擬化功能
開始實戰演練，首先在Level 0層級實體伺服器環境中，安裝Hyper-V伺服器虛擬化角色，本文實作環境採用最新Windows Server 2025雲端作業系統，如圖6所示，可以透過伺服器管理員或PowerShell指令進行安裝作業。
圖6 Level 0層級實體伺服器安裝最新Windows Server 2025雲端作業系統。
採用GUI圖形介面伺服器管理員進行安裝作業時，依序點選「Server Manager > Add Roles and Features > Role-based or feature-based installation > Hyper-V > Create Virtual Switches > Virtual Machine Migration > Default Stores > Confirm installation selections > Restart the destination server automatically if required」，當Hyper-V伺服器角色安裝完畢，系統便會自動重新啟動主機。
或是開啟PowerShell指令視窗，先執行「hostname」指令，確認Level 0層級實體伺服器的主機名稱，本文實作環境主機名稱為「Parent-HV」。接著，鍵入「Install-WindowsFeature -Name Hyper-V -ComputerName Parent-HV -IncludeManagementTools -Restart」指令，如圖7所示，安裝Hyper-V伺服器角色及相關管理工具後重新啟動主機。
圖7 Level 0層級實體伺服器，安裝Hyper-V伺服器角色及管理工具。
在建立Level 1層級的VM虛擬主機時，若希望屆時能夠啟用並支援Hyper-V巢狀式虛擬化技術，需要注意下列重要事項，避免屆時無法順利啟用Hyper-V巢狀式虛擬化技術：
‧VM虛擬主機必須採用「第2世代」格式，以及至少「8.0」的VM虛擬主機組態版本。請注意，VM虛擬主機世代一旦選擇後便無法更改世代，只能重新建立VM虛擬主機。
‧Level 0層級實體主機，必須為Level 1層級VM虛擬主機啟用vCPU處理器的虛擬化擴充功能，Level 1層級VM虛擬主機才能接收Level 0層級Hyper-V虛擬化平台傳遞的硬體輔助虛擬化技術，進而再建立巢狀VM虛擬主機。
‧巢狀虛擬化環境中的VM虛擬主機，建議「停用」動態記憶體功能。雖然啟用動態記憶體功能不影響VM虛擬主機的運作，但屆時嘗試調整記憶體空間大小時，將會發生調整失敗的情況。
‧巢狀虛擬化環境中，VM虛擬主機必須啟用MAC Address Spoofing機制，或建立具備NAT功能的vSwitch虛擬網路交換器，否則屆時建立的Nested VM虛擬主機，將會發生無法與實體網路環境連通或連線至網際網路的情況。
在本文實作環境中，建立Level 1層級的VM虛擬主機名稱為「Guest-HV」，並採用第二世代格式，而VM虛擬主機組態設定格式為最新的「12.0」版本，如圖8所示。
圖8 Level 1層級的VM虛擬主機，建立時採用第二世代格式及12.0組態版本。
Level 1啟用巢狀式虛擬化技術
登入Level 1層級的Guest-HV虛擬主機後，同樣透過伺服器管理員或PowerShell指令，嘗試安裝Hyper-V伺服器角色，然而當勾選「Hyper-V」伺服器角色項目後，在系統執行檢查程序完畢，將會出現「無法安裝Hyper-V：處理器沒有所需要的虛擬化功能」的錯誤訊息，如圖9所示。
圖9 Level 1層級的VM虛擬主機無法安裝Hyper-V伺服器角色。
此時，可透過微軟官方工具Sysinternals – Coreinfo（下載網址：https://learn.microsoft.com/en-us/sysinternals/downloads/coreinfo?WT.mc_id=AZ-MVP-4039747），檢查Level 1層級的VM虛擬主機虛擬化擴充功能狀態。下載後解壓縮無須安裝，在命令提示字元視窗中鍵入「coreinfo64.exe -v」指令，即可檢查在Level 1層級的Guest-HV虛擬主機中是否具備Intel VT-x及EPT硬體輔助虛擬化功能。如圖10所示，從檢查結果中可以看到，Level 1層級的Guest-HV虛擬主機，並沒有接收到底層Level 0主機傳遞過來的硬體輔助虛擬化功能，才會導致無法順利安裝Hyper-V伺服器角色。
圖10 Level 1層級的Guest-HV虛擬主機未具備硬體輔助虛擬化功能。
因此，必須為Level 1層級的Guest-HV虛擬主機執行啟用巢狀式虛擬化技術，正確接收來至底層Level 0主機向上傳遞的硬體輔助虛擬化功能，一旦接收並具備Intel VT-x及EPT硬體輔助虛擬化技術後，Level 1層級的Guest-HV虛擬主機便能順利安裝Hyper-V伺服器角色。
值得注意的是，當準備為Level 1層級的Guest-HV虛擬主機啟用巢狀式虛擬化技術時，Guest-HV虛擬主機必須為「關機」（Power Off）狀態，才能透過PowerShell指令啟用巢狀式虛擬化技術。如果是「開機中」（Power On）狀態，啟用巢狀式虛擬化技術時，將會出現「修改Processor處理器失敗」的錯誤訊息。
確認Level 1層級的Guest-HV虛擬主機關機後，在Level 0層級的Parent-HV主機中，開啟PowerShell指令視窗，並執行「Set-VMProcessor -VMName Guest-HV -ExposeVirtualizationExtensions $true」指令，啟用巢狀式虛擬化技術，並再次確認Guest-HV虛擬主機屬性中，ExposeVirtualizationExtensions欄位值是否轉變為「True」，以便確認變更作業是否套用生效，確認後便可以將Guest-HV虛擬主機開機，如圖11所示。
圖11 為Level 1層級Guest-HV虛擬主機啟用巢狀式虛擬化技術。
Level 1層級Guest-HV虛擬主機開機完成後，再次在命令提示字元視窗中鍵入「coreinfo64.exe -v」指令，如圖12所示，從檢查結果中可以看到，Level 1層級的Guest-HV虛擬主機，確實接收到由底層Level 0主機傳遞過來的Intel VT-x及EPT硬體輔助虛擬化功能，如此一來，便能順利安裝Hyper-V伺服器角色。
圖12 Level 1層級Guest-HV虛擬主機，順利接收底層傳遞而來的硬體輔助虛擬化功能。
巢狀網路1 - MAC位址變更
當順利為Level 1層級Guest-HV虛擬主機，安裝Hyper-V伺服器角色，並建立Level 2層級名稱為「Nested-VM01」虛擬主機後，將會發現雖然Nested-VM01虛擬主機的網路組態設定正確無誤，並且連接至正確的vSwitch虛擬網路交換器，但卻無法與實體網路環境溝通或連接到網際網路，如圖13所示。
圖13 Level 2層級虛擬主機無法和實體網路溝通。
這個問題的原因在於，Level 2層級的Nested-VM01虛擬主機，網路封包必須通過Level 1層級主機後，才能和Level 0層級的vSwitch虛擬網路交換器連接，也才能與實體網路環境或網際網路環境通訊。因此，Level 2層級的網路封包要能夠正確路由的話，必須為Level 1層級的vSwitch虛擬網路交換器啟用「MAC位址欺騙」（MAC Address Spoofing）功能，Level 2層級的網路封包才能正確通過Level 1層級，並使用Level 0層級的路由機制，與實體網路環境或網際網路通訊。
管理人員有兩種方式為Level 1層級的Guest-HV虛擬主機啟用MAC位址欺騙功能。首先，登入Level 0層級Parent-HV實體主機，開啟PowerShell指令視窗，然後鍵入「Get-VMNetworkAdapter -VMName Guest-HV | Set-VMNetworkAdapter -MacAddressSpoofing On」指令，並於指令執行成功後，確認Level 1層級Guest-HV虛擬主機屬性中名稱為「MacAddressSpoofing」的欄位值是否轉變為「On」，確認MAC位址欺騙功能已經套用生效，如圖14所示。
圖14 在Level 0層級為Level 1層級主機啟用MAC位址欺騙功能。
習慣使用Hyper-V Manager圖形化介面的管理人員也可以開啟Level 1層級Guest-HV虛擬主機組態設定視窗，先依序點選「Network Adapter > Advanced Features > MAC address」選項，如圖15所示，再勾選「Enable MAC address spoofing」並按下〔OK〕鈕，即可套用生效。
圖15 透過Hyper-V Manager為Level 1層級主機啟用MAC位址欺騙功能。
此時，切換回Level 2層級的Nested-VM01虛擬主機，執行「ipconfig /renew」指令，可以發現送出的DHCP Client請求網路封包已經能夠順利通過Level 1層級的vSwitch虛擬交換器，直接向Level 0層級的DHCP伺服器請求獲得IP位址，如圖16所示，當然也可以與實體網路環境或網際網路進行通訊。
圖16 Level 2層級主機順利和Level 0層級實體網路環境進行通訊。
巢狀網路2–NAT網路位址轉換
在上述巢狀網路方法1的情境中，適合用於企業及組織自建的Hyper-V虛擬化環境，因為可以掌控Level 0層級的實體伺服器，為Level 1層級的VM虛擬主機啟用MAC位址欺騙功能，讓Level 2層級的巢狀VM虛擬主機的網路封包，能夠正確通過vSwitch虛擬網路交換器後，正確路由至Level 0層級的實體網路環境。
然而，一旦Hyper-V虛擬化環境運作在管理人員無法掌控Level 0層級的實體伺服器時，便無法為Level 1層級的VM虛擬主機啟用MAC位址欺騙功能。舉例來說，當企業和組織使用Azure公有雲環境時，由於部署使用的Azure VM虛擬主機已經屬於Level 1層級的VM虛擬主機，企業和組織無法碰觸到Azure公有雲環境中屬於Level 0層級的Hyper-V主機，自然就無法為Level 1層級VM虛擬主機啟用MAC位址欺騙功能。
此時，便適合使用此情境，在Level 1層級Guest-HV虛擬主機上，建立具備NAT網路位址轉換功能的vSwitch虛擬網路交換器，以便Level 2層級的Nested-VM01虛擬主機，可以透過Level 1層級的NAT網路位址轉換機制，讓Level 2層級的網路封包能夠被正確路由，進而與Level 0層級的實體網路環境或網際網路進行通訊。
在實作巢狀網路方法2之前，先將剛才巢狀網路方法1的機制取消，在Level 1層級Guest-HV虛擬主機取消MAC位址欺騙功能，以避免影響和驗證實作巢狀網路方法2的正確性。
在Level 1層級Guest-HV虛擬主機上，開啟的PowerShell指令視窗中，執行「New-VMSwitch -Name Level1-NAT-vSwitch –SwitchType Internal」指令，建立名稱為「Level1-NAT-vSwitch」且類型為「內部」（Internal）的vSwitch虛擬網路交換器。
接著，執行「New-NetNat -Name LocalNAT -InternalIPInterfaceAddressPrefix "192.168.75.0/24"」指令，建立名稱為「LocalNAT」且網段為「192.168.75.0/24」的NAT網路位址轉換環境，如圖17所示。
圖17 建立網段為192.168.75.0/24的NAT網路位址轉換環境。
最後，為剛才建立名稱為Level1-NAT-vSwitch的虛擬網路交換器指定採用的IP位址即可。在開啟的PowerShell指令視窗中，執行「Get-NetAdapter "vEthernet (Level1-NAT-vSwitch)" | New-NetIPAddress -IPAddress 192.168.75.254 -AddressFamily IPv4 -PrefixLength 24」指令，如圖18所示。事實上，Level1-NAT-vSwitch虛擬網路交換器的IP位址，也是屆時Level 2虛擬網路環境的預設閘道IP位址。 現在為避免巢狀網路方法1的影響，登入Level 2層級的Nested-VM01虛擬主機後，先在Cmd命令提示字元視窗中，執行「ipconfig /release」指令，將巢狀網路方法1透過DHCP Client機制所獲取的10.10.75.0/24網段的IP位址釋放。
圖18 為Level1-NAT-vSwitch虛擬網路交換器指定IP位址。
為Level 2層級的Nested-VM01虛擬主機，調整網路介面卡所連接的vSwitch虛擬網路交換器，在本文實作環境中，改為連接至剛才所建立的Level1-NAT-vSwitch虛擬網路交換器，而在網路卡組態設定方面，指派IP位址為192.168.75.20，預設閘道IP位址為192.168.75.254，如圖19所示。
圖19 Level 2層級Nested-VM01虛擬主機透過NAT機制與實體網路環境通訊。
再建立Level 3層級VM虛擬主機？
至此，已經順利在最新Windows Server 2025雲端作業系統，透過原生內建的Hyper-V巢狀式虛擬化技術，建立Nested VM巢狀式運作環境，讓管理人員只要透過一台x86硬體伺服器，便能建構出「Level 0 Hyper-V實體主機 > Level 1 VM虛擬主機 > Level 2巢狀式VM虛擬主機」的Hyper-V巢狀式虛擬化運作環境。
那麼有沒有可能在Level 2層級巢狀式VM虛擬主機中，建立Level 3層級的巢狀式VM虛擬主機？事實上是可行的，只要依照先前提到的Hyper-V巢狀式虛擬化技術滿足運作環境需求及限制時，便可以讓Level 2層級巢狀式VM虛擬主機，再部署出Level 3層級巢狀式VM虛擬主機。
值得注意的是，在操作Level 2層級巢狀式VM虛擬主機時，管理人員應該有感受到，在操作流暢度上與Level 1 VM虛擬主機的差別，所以在技術上雖然能夠由Level 2層級再次部署出Level 3層級的巢狀式VM虛擬主機，但實務上並不會真實使用，因為在操作流暢度和效能表現上並無法令人接受。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞