網管人雜誌
本文刊載於
網管人雜誌第 133 期 - 2017 年 2 月 1 日出刊，
NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。
文章目錄
前言實戰 Hyper-V 巢狀式虛擬化 Guest Hypervisor 安裝 Hyper-V 角色 Guest Hypervisor 啟用 MAC 位址變更機制 Guest Hypervisor 啟用 NAT 機制 Nested VM 再生 Nested VM？結語前言
在伺服器虛擬化運作環境中，談到「
巢狀式虛擬化」（
Nested Virtualization）的運作環境時，大家通常都會想到 VMware vSphere 虛擬化解決方案。沒錯，在過去的 Hyper-V 虛擬化平台當中，要建構出「巢狀式虛擬化」的運作環境，確實非常困難並且難以達成的。現在，透過最新發行的 Windows Server 2016 雲端作業系統，所建構的 Hyper-V 虛擬化平台便能原生內建支援「巢狀式虛擬化」運作機制。
事實上，從 Windows Server 2016技術預覽版本 4 的「10565」組建號碼開始，便原生內建支援巢狀式虛擬化機制。
簡單來說，在過去舊版 Hyper-V 虛擬化平台運作架構中，最底層 Hyper-V Hypervisor 虛擬化管理程序，將會完全管控「
虛擬化擴充功能」（
Virtualization Extensions）的部分，也就是如圖 1 所示中「
橘色箭頭」的部分。同時，Hyper-V Hypervisor 並不會將底層硬體輔助虛擬化功能，傳遞給運作於上層的客體作業系統，所以在舊版的 Hyper-V 虛擬化平台上很難實作出巢狀式虛擬化的運作環境。
圖 1、舊版 Hyper-V 虛擬化平台運作架構（不支援巢狀式虛擬化）
現在，透過最新 Windows Server 2016 雲端作業系統所建置的 Hyper-V 虛擬化平台當中，Hyper-V Hypervisor 虛擬化管理程序，已經可以順利將「
虛擬化擴充功能」也就是底層硬體輔助虛擬化技術，傳遞給 Hyper-V 虛擬化平台上運作的客體作業系統了。
因此，當 Hyper-V 虛擬化平台上運作的客體作業系統為 Windows Server 2016 時，因為能夠順利接收到由底層所傳遞過來的硬體輔助虛擬化技術，所以便能啟用 Hyper-V 虛擬化功能並建立 VM 虛擬主機，達成 VM 虛擬主機中再生出 VM 虛擬主機的巢狀式虛擬化運作架構。
事實上，當客體作業系統運作 Windows 10時，也能順利接收底層所傳遞過來的硬體輔助虛擬化技術，達成 VM 虛擬主機中再生出 VM 虛擬主機的巢狀式虛擬化運作架構。
圖 2、新版 Hyper-V 虛擬化平台運作架構（支援巢狀式虛擬化）
此外，一般對於巢狀式虛擬化技術的認知，僅止於建立測試研發環境上具備方便度而已，通常在線上營運的運作環境中並不會使用到巢狀式虛擬化技術。然而，在新版 Windows Server 2016 中 Hyper-V 虛擬化平台支援巢狀式虛擬化技術，並非只是為了達到 Nested VM 這種 VM 虛擬主機再生出 VM 虛擬主機，方便建立測試研發環境的目的而已。
在新一代 Windows Server 2016 雲端作業系統運作環境中，同時支援 Windows Containers 及 Hyper-V Container 這 2 種容器技術運作環境，其中「
Hyper-V Container」容器技術運作環境的部分，便是在 VM 虛擬主機中再運作 Container 容器環境，達到更進一步的容器技術隔離運作環境。事實上，Hyper-V Container 的容器技術運作環境，便是透過 Hyper-V 巢狀式虛擬化技術所達成的。
圖 3、Windows Containers 與 Hyper-V Containers 運作架構示意圖
實戰 Hyper-V 巢狀式虛擬化
在開始實作 Hyper-V 巢狀式虛擬化機制之前，我們先了解建立 Hyper-V 巢狀式虛擬化的運作環境需求以及相關限制：
Hyper-V 主機（Hyper-V Hypervisor）- 運作 Hyper-V 巢狀式虛擬化技術的實體伺服器，在 CPU 處理器硬體輔助虛擬化技術的部分，必須採用支援「Intel VT-x 及 EPT」虛擬化擴充功能的 CPU 處理器才行。
- 作業系統的部分，必須採用 Windows 10 年度更新版（Enterprise、Professional、Education）或 Windows Server 2016（Standard、Datacenter）等版本。
VM 虛擬主機（Guest Hypervisor）- 必須採用「第 2 世代」以及新版「8.0」的 VM 虛擬主機格式。
- 作業系統的部分，必須採用 Windows 10年度更新版（Enterprise、Professional、Education）或 Windows Server 2016（Standard、Datacenter）等版本。
- 必須「啟用」vCPU 虛擬處理器的虛擬化擴充功能，才能夠順利接收由底層 Hyper-V 虛擬化平台所傳遞的硬體輔助虛擬化技術。
- 建議「停用」動態記憶體功能。雖然，啟用動態記憶體功能仍然不影響 VM 虛擬主機的運作，但倘若嘗試調整記憶體空間大小時（也就是執行 Runtime Memory Resize 的動作），將會發生失敗的情況。
- 必須「啟用」MAC Address Spoofing 機制，或建立具備 NAT 功能的 vSwitch 虛擬網路交換器，否則屆時建立的 Nested VM 虛擬主機，將會發生無法與實體網路環境連通或連線至網際網路的情況。
上述 Hyper-V 巢狀式虛擬化的運作環境需求僅為大方向的重點規劃要項，下列將針對 Hyper-V 實體伺服器在 CPU 處理器及記憶體方面的選擇及規劃給予建議。
CPU 處理器的選擇事實上，從 Windows Server 2008 R2 作業系統版本開始，Windows Server 便僅提供 64 位元的作業系統版本，當然 Windows Server 2012 和 2012 R2 以及新世代的雲端作業系統 Windows Server 2016 也不例外。因此，在選擇原生 64 位元的 CPU 處理器時，請選擇具備更多「
定址空間」及具備大容量「
L2 / L3 快取」空間的 CPU 處理器，甚至較新世代的處理器如 Intel Haswell、Broadwell 更支援
L4 快取，當擔任 Hyper-V 角色的硬體伺服器配置這樣的 CPU 處理器時，將能夠讓 Hyper-V 伺服器擁有更強大的運算資源。
請注意，雖然從 Windows Server 2008 R2 作業系統版本開始，Windows Server 便不再發行 32 位元版本，但是在原生 64 位元的 Windows Server 環境中運作 32 位元的應用程式，並不會有任何問題產生。
至於，在選擇 CPU 處理器時，應該選擇追求「
高時脈」以得到高效能的運算速度，或者是著重在選擇「
多核心」以達到平行運算，則應該視屆時運作於 Hyper-V 虛擬化平台上 VM 虛擬主機當中的工作負載類型而定，舉例來說，倘若 VM 虛擬主機當中的應用程式是屬於「
單線程」（
Single-Thread）類型的話，那麼便應該選擇採用「高時脈」類型的 CPU 處理器，倘若 VM 虛擬主機當中的應用程式是屬於「
多線程」（
Multi-Thread）類型的話，那麼便應該選擇採用「多核心」類型的 CPU 處理器，如此一來才能夠讓 VM 虛擬主機當中的工作負載得到最佳化的運算效能。
此外，在選擇 CPU 處理器硬體輔助虛擬化技術的部分，目前主流的 CPU 處理器皆已經支援第一代硬體輔助虛擬化技術（例如，Intel VT-x 或 AMD-V），以及第二代硬體輔助虛擬化技術或稱第二層位址轉譯 SLAT（例如，Intel EPT 或 AMD NPT），以便降低因為虛擬化技術所造成的硬體資源耗損。
請注意，在 Windows Server 2016 所建構的 Hyper-V 虛擬化平台中，倘若要建立 Hyper-V 巢狀式虛擬化運作環境的話，目前僅支援 Intel 處理器的硬體輔助虛擬化技術「Intel VT-x 及 EPT」，尚未支援採用 AMD處理器「AMD-V 及 NPT」虛擬化擴充功能建立 Hyper-V 巢狀式虛擬化運作環境。
Memory 記憶體的選擇在建構 Hyper-V 虛擬化平台的硬體伺服器上，針對實體記憶體的部分當然是越多越好。因為，當實體伺服器記憶體空間不足時，便會迫使 Windows Server 透過硬碟空間產生「分頁檔案」，以便嘗試渡過記憶體空間不敷使用的情況，此時將會直接影響並降低實體伺服器的運作效能。
倘若，因為 IT 預算的關係在短期之內真的無法購足實體記憶體時，則會建議應該依照如下準則來優化分頁檔案的運作效率：
- 請將分頁檔案產生在實體隔離的硬碟環境，也就是不要跟作業系統或應用程式共用同一個硬碟空間。
- 雖然將分頁檔案建立在具備容錯機制的硬碟空間中（例如，RAID 1），可能會導致更慢的儲存 I/O 效能，但是倘若將分頁檔案存放於「未」具備容錯機制的硬碟空間時，雖然會獲得較快的儲存 I/O 效能，然而一旦該硬碟發生災難事件時可能會導致「系統崩潰」的情況發生。
- 請保持分頁檔案隔離原則，不要將「多個」分頁檔案同時建立在同一個硬碟內。
此外，應該要選擇
支援 NUMA 架構的實體伺服器，以避免 CPU 處理器與記憶體之間的資料存取行為，因為匯流排頻寬不足的問題而產生存取瓶頸。值得注意的是，當採用支援 NUMA 架構的實體伺服器時，必須要注意實體記憶體空間必須平均分配到不同的 NUMA 節點，以避免 CPU 處理器仍需跨越 NUMA 節點進行記憶體空間的存取。
了解，上述 Hyper-V 伺服器在 CPU 處理器及記憶體的選擇規劃，以及實作 Hyper-V 巢狀式虛擬化的運作環境需求及限制等準則之後，接著便可以開始實作 Nested VM 巢狀式虛擬化運作環境。
Guest Hypervisor 安裝 Hyper-V 角色
首先，我們在實體伺服器所建構的 Hyper-V 虛擬化平台中，建立擔任 Guest Hypervisor 角色名稱為「
WS2016-Outer」的 VM 虛擬主機，同時採用「第 2 世代」以及新版「8.0」的 VM 虛擬主機格式，在客體作業系統的部分則是採用 Windows Server 2016 DataCenter 版本。
圖 4、建立擔任 Guest Hypervisor 角色的 VM 虛擬主機
登入 WS2016-Outer 虛擬主機之後，我們可以直接開啟伺服器管理員並嘗試安裝 Hyper-V 伺服器角色，然而你會發現當你勾選「
Hyper-V」伺服器角色項目後，在系統執行檢查程序完畢時將會出現「
無法安裝 Hyper-V：處理器沒有必要的虛擬化功能」的錯誤訊息。
圖 5、擔任 Guest Hypervisor 角色的 VM 虛擬主機，無法順利安裝 Hyper-V 伺服器角色
此時，我們可以透過
Coreinfo虛擬化擴充功能檢查工具，下載後解壓縮無須安裝直接在開啟的命令提示字元視窗中鍵入「
coreinfo.exe -v」指令，便可以檢查目前在 WS2016-Outer 虛擬主機中，是否擁有 Intel VT-x 及 EPT 硬體輔助虛擬化功能。如圖 6 所示，可以看到在檢查的顯示結果中，目前擔任 Guest Hypervisor 角色的虛擬主機並沒有任何的硬體輔助虛擬化功能，所以才會導致無法順利安裝 Hyper-V 伺服器角色。
圖 6、目前擔任 Guest Hypervisor 角色的虛擬主機並沒有任何硬體輔助虛擬化功能
因此，我們必須為擔任「
Guest Hypervisor」角色的 VM 虛擬主機，執行「
啟用」vCPU 虛擬處理器虛擬化擴充功能的動作，如此一來 VM 虛擬主機才能順利接收，由底層 Hyper-V 虛擬化平台所傳遞而來的 Intel VT-x 及 EPT 硬體輔助虛擬化技術。
值得注意的是，擔任 Guest Hypervisor 角色的 VM 虛擬主機必須為「
關機（Power Off）」狀態，才能透過 PowerShell 順利執行啟用 vCPU 虛擬處理器虛擬化擴充功能的動作，倘若 VM 虛擬主機為「
運作中（Power On）」狀態的話，那麼當你執行啟用 vCPU 虛擬處理器虛擬化擴充功能的動作時，將會得到 PowerShell 指令執行失敗的情況。
圖 7、VM 虛擬主機必須關機，否則啟用 vCPU 虛擬處理器虛擬化擴充功能的動作會失敗
順利將 WS2016-Outer 虛擬主機關機後，便可以執行啟用 vCPU 虛擬處理器虛擬化擴充功能的動作，並且於指令執行完畢後再次確認 VM 虛擬主機屬性中，「
ExposeVirtualizationExtensions」的欄位值是否為「
True」以便確認變更作業已經套用生效。
圖 8、確認 VM 虛擬主機是否啟用 vCPU 虛擬處理器虛擬化擴充功能
請將擔任 Guest Hypervisor 角色的 VM 虛擬主機重新開機並登入後，再次執行 Coreinfo 虛擬化擴充功能檢查作業。如圖 9 所示，可以看到在檢查的顯示結果中，擔任 Guest Hypervisor 角色的虛擬主機，已經順利接收到由底層 Hyper-V 虛擬化平台所傳遞而來的 Intel VT-x 及 EPT 硬體輔助虛擬化技術。
圖 9、VM 虛擬主機，順利接收底層 Hyper-V 虛擬化平台傳遞的 Intel VT-x 及 EPT 硬體輔助虛擬化技術
此時，請開啟伺服器管理員並再次嘗試為 WS2016-Outer 虛擬主機，安裝 Hyper-V 伺服器角色時便可以發現能夠順利新增並安裝完成。
圖 10、順利為 WS2016-Outer 虛擬主機安裝 Hyper-V 伺服器角色
Guest Hypervisor 啟用 MAC 位址變更機制
當你順利為 WS2016-Outer 虛擬主機安裝 Hyper-V 伺服器角色，並且在 WS2016-Outer 虛擬主機中建立名稱為「
WS2016-Inner」的虛擬主機後，此時你將會發現 WS2016-Inner 虛擬主機的網路組態設定雖然正確無誤，但是它卻無法順利與實體網路環境溝通或連接到網際網路？
主要原因在於，在 Hyper-V 巢狀式虛擬化運作架構中的 VM 虛擬主機（又稱為
Nested VM虛擬主機），必須在上層 Guest Hypervisor 虛擬主機中，啟用「
MAC 位址變更」（
MAC Address Spoofing）功能，以便 Nested VM 虛擬主機的網路封包，能夠順利在 2 層（Hyper-V Hypervisor 及 Guest Hypervisor）虛擬網路交換器之間順利路由，才能夠與實體網路環境溝通或碰觸到網際網路。
因此，Hyper-V 主機的管理人員可以透過 PowerShell 指令，或者是 Hyper-V 管理員操作介面進行啟用 MAC 位址變更的動作。倘若，透過 PowerShell 指令進行組態設定的話，請在 Hyper-V 主機指定為「WS2016-Outer」虛擬主機開啟 MAC 位址變更功能，並於執行後再次確認 VM 虛擬主機屬性中「MacAddressSpoofing」欄位值為「On」，以便確認變更作業已經套用生效。
圖 11、透過 PowerShell 指令，為 Guest Hypervisor 啟用 MAC 位址變更功能
或者，管理人員也可以開啟 Hyper-V 管理員操作介面，選擇 WS2016-Outer 虛擬主機後依序點選「設定 > 網路介面卡 > 進階功能」項目，然後勾選「啟用 MAC 位址變更」選項即可。
圖 12、透過 Hyper-V 管理員，為 Guest Hypervisor 虛擬主機啟用 MAC 位址變更功能
完成 Guest Hypervisor 虛擬主機啟用 MAC 位址變更功能的組態設定後，便可以發現「WS2016-Inner」Nested VM 虛擬主機，已經可以順利通過 WS2016-Outer 這台 Guest Hypervisor 的 vSwitch 虛擬網路交換器，以及 HV01 這台 Hyper-V 實體伺服器的 vSwitch 虛擬網路交換器進行路由，進而與實體網路環境溝通或碰觸到網際網路。
圖 13、Nested VM 虛擬主機，順利在 2 層 vSwitch 虛擬網路交換器之間順利路由
Guest Hypervisor 啟用 NAT 機制
當 Guest Hypervisor 虛擬主機，運作在你能掌控的 Hyper-V 虛擬化平台時，便可以透過上述 PowerShell 指令或 Hyper-V 管理員，幫 Guest Hypervisor 虛擬主機啟用 MAC 位址變更功能，進而讓 Nested VM 虛擬主機能夠與實體網路環境溝通或碰觸到網際網路。
倘若，Guest Hypervisor 虛擬主機運作在你「
無法」掌控的 Hyper-V 虛擬化平台時，例如，Microsoft Azure 公有雲服務。或者，其它並非採用 Hyper-V 虛擬化解決方案的虛擬化平台，例如，Amazon AWS 公有雲服務 、VMware vSphere 虛擬化解決方案……等。
此時，便需要在 Guest Hypervisor 虛擬主機端，建立具備 NAT 功能的 vSwitch 虛擬網路交換器，以便屆時在 Guest Hypervisor 中所產生的 Nested VM 虛擬主機，能夠順利與實體網路環境溝通或碰觸到網際網路。
請在 Guest Hypervisor 虛擬主機端，執行 PowerShell 指令或透過 Hyper-V 管理員操作介面，建立類型為「
內部」（
Internal）的 vSwitch 虛擬網路交換器。如圖 14 所示，我們透過「
New-VMSwitch」的 PowerShell 指令建立名稱為「
VM-NAT」，並且類型為內部的 vSwitch 虛擬網路交換器，然後透過 Hyper-V 管理員操作介面驗證是否建立完成。
圖 14、建立屆時 Nested VM 虛擬主機對外溝通連線的 vSwitch 虛擬網路交換器
接著，再次執行「
New-NetNat」的 PowerShell 指令，建立屆時用於 NAT 運作機制中的 IP 網段，在本文實作環境中建立名稱為「
LocalNAT」，並且採用「
192.168.100.0/24」IP 網段的 NAT 網路環境。
圖 15、建立屆時用於 NAT 運作機制中的 IP 網段網路環境
最後，再為剛才所建立名稱為 VM-NAT 的虛擬網路交換器指定所要採用的 IP 位址即可。在本文實作環境中，我們指派 VM-NAT 虛擬網路交換器採用「
192.168.100.254」的 IP 位址，屆時 Nested VM 虛擬主機在設定網路組態時，便需要將預設閘道的 IP 位址設定為 192.168.100.254 後，才能順利與實體網路環境溝通或碰觸到網際網路。
圖 16、為 VM-NAT 虛擬網路交換器指派使用 192.168.100.254 的 IP 位址
在 Guest Hypervisor 虛擬主機端進行 NAT 組態設定的動作執行完畢後，首先請為 Nested VM 虛擬主機調整該網路介面卡所連接的 vSwitch 虛擬網路交換器，在本文實作環境中便是將 WS2016-Inner 虛擬主機的網路介面卡，改為連接至剛才我們所建立的 VM-NAT 虛擬網路交換器，然後在設定網路組態的部分則是指派為 192.168.100.10，當然最重要的是預設閘道必須指向至 192.168.100.254 的 IP 位址。此時，Nested VM 虛擬主機便可以順利透過 WS2016-Outer 虛擬主機，也就是 Guest Hypervisor 的 VM-NAT 虛擬網路交換器進行 NAT 進而能夠碰觸到網際網路。
圖 17、Nested VM 虛擬主機，透過具備 NAT 功能的 vSwitch 虛擬網路交換器碰觸到網際網路
Nested VM 再生 Nested VM？
至此，我們已經順利透過新一代 Windows Server 2016 雲端作業系統，原生內建的 Hyper-V 巢狀式虛擬化技術建立 Nested VM 運作環境，讓管理人員只要透過 1 台硬體伺服器，便能建立出「
Hyper-V Host > Guest Hypervisor > Nested VM」的 Hyper-V 巢狀式虛擬化運作環境。
那麼，有沒有可能更進一步在 Nested VM 虛擬主機中再生出 Nested VM 虛擬主機？答案是可行的，只要遵循前述所條列的 Hyper-V 巢狀式虛擬化技術運作環境需求及限制，便可以讓 Nested VM 再生出 Nested VM 虛擬主機。
因為實作方式與前述的操作步驟相同所以便不再贅述，如圖 18 所示我們總共建立出 4 層的 Hyper-V 巢狀式虛擬化技術運作環境：
第 1 層（HV01）：Hyper-V Hypervisor 實體伺服器。
第 2 層（WS2016-Outer）：VM 虛擬主機並擔任 Guest Hypervisor。
第 3 層（WS2016-Inner）：Nested VM 虛擬主機並再擔任 Guest Hypervisor。
第 4 層（WS2016-Innermost）：由 Nested VM 再生出的 Nested VM 虛擬主機。
圖 18、由 Nested VM 再生出的 Nested VM 虛擬主機
結語
透過本文的說明及實作演練，相信讀者已經完全了解新一代 Windows Server 2016 雲端作業系統中，原生內建的 Hyper-V 巢狀式虛擬化的強大功能，善用此機制相信能夠有效幫助管理人員只要利用少量的實體伺服器，就能夠建構出複雜的測試研發環境有效減少過往建立測試研發環境時的困擾。
