網管人雜誌
本文刊載於
網管人雜誌第 185 期 - 2021 年 6 月 1 日出刊，NetAdmin 網管人雜誌
為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology
Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
在過去的微軟 Hyper-V 虛擬化平台中，一直遲遲未支援深受管理人員喜愛的巢狀式虛擬化技術。直到 Windows Server 2016 版本時，微軟的 Hyper-V 虛擬化平台便開始內建支援「巢狀式虛擬化」（Nested Virtualization）運作環境，除了方便管理人員建構研發和測試環境之外，更重要的是將巢狀式虛擬化和 Windows「容器」（Container）技術進行整合。
在過去的 Windows Server 版本中，非常難以實作出巢狀式虛擬化環境，即便實作成功後微軟官方也不支援該運作環境。
在典型的 Linux 容器運作環境中，在 Linux 主機上層運作的容器透過命名空間、資源控制和執行程序隔離的方式，讓多種不同服務的容器同時運作在同一台 Linux 主機上，並且上層運作的容器和底層的 Linux 主機共用相同的系統核心。在 Windows 容器技術中，採用隔離模式為「執行程序」（Process）時，便是和典型的 Linux 容器環境大致相同（如圖 1 所示）。
圖 1、採用執行程序隔離模式的 Windows Server Container 運作架構示意圖
雖然，採取執行程序隔離模式時具有一定強度的安全性，然而對於強度高度安全性和完全隔離需求的企業和組織來說可能不足。因此，微軟透過巢狀式虛擬化搭配 Windows 容器技術，發展出相容性更佳且高度安全性的「Windows Hyper-V Container」技術（如圖 2 所示）。簡單來說，採用隔離模式為「Hyper-V」的容器，將會運作在微軟高度客製化和組態最佳化的特殊 VM 虛擬主機中，每個容器皆可以安全且完整的使用 VM 虛擬主機核心，充分為不同的容器之間提供硬體層級的隔離機制。
圖 2、Windows Hyper-V Container 運作架構示意圖
巢狀式虛擬化環境需求
在開始實作巢狀式虛擬化技術之前，管理人員必須先確保運作環境滿足相關條件，後續才能順利在 Hyper-V 虛擬化平台中，為運作的 VM 虛擬主機啟用巢狀式虛擬化技術。
首先，在 Hyper-V 虛擬化平台的硬體伺服器方面，必須採用支援「Intel VT-x 和 EPT」硬體輔助虛擬化技術的 CPU 處理器，並且 Hyper-V 虛擬化平台的伺服器版本，至少要採用「Windows Server 2016」或後續版本，建立的 VM 虛擬主機組態設定版本必須為「8.0」或後續版本。
採用 AMD Ryzen/EPYC 處理器的硬體伺服器，必須採用 Windows OS build number「19636」或後續版本，並且採用「9.3」VM 虛擬主機組態版本，才能支援啟用巢狀式虛擬化技術。有關 AMD CPU 處理器支援巢狀式虛擬化的詳細資訊，請參考微軟官方說明 Microsoft Tech Community - AMD Nested Virtualization Support。
值得注意的是，啟用巢狀式虛擬化技術後的第二層 VM 虛擬主機，在 vNetwork 虛擬網路組態設定方面，與一般正常的第一層 VM 虛擬主機有所不同。目前，Hyper-V 虛擬化平台支援兩種不同的作法，分別是「MAC 位址欺騙」（MAC Address Spoofing）和「網路位址轉譯」（Network Address Translation，NAT）。
當管理人員能夠碰觸和管理 Hyper-V 虛擬化平台時，例如，企業和組織在內部資料中心內，建立的 Hyper-V 虛擬化平台便建議採用 MAC 位址欺騙方式（如圖 3 所示），讓第二層 VM 虛擬主機的網路封包，能夠在 vSwitch 虛擬交換器進行路由。當管理人員無法碰觸 Hyper-V 虛擬化平台時，例如，公有雲環境，建議採用 NAT 網路位址轉譯的方式，在第一層 VM 虛擬主機中建立 NAT vSwitch 虛擬交換器，幫助第二層 VM 虛擬主機的網路封包進行路由。
圖 3、啟用 MAC 位址欺騙機制，以便啟用巢狀式虛擬化的 VM 虛擬主機網路封包能夠進行路由
此外，建議第二層 VM 虛擬主機應「停用」動態記憶體功能。因為，第二層 VM 虛擬主機即便啟用動態記憶體功能，除了記憶體空間不會動態調整和變動之外，管理人員在第二層 VM 虛擬主機運作時，倘若嘗試調整記憶體空間大小時將會遭遇失敗，必須將第二層 VM 虛擬主機關機後才能調整記憶體空間大小。
巢狀式虛擬化運作架構
在過去 Hyper-V 虛擬化平台尚未支援巢狀式虛擬化技術時，一旦硬體伺服器安裝並啟用 Hyper-V 虛擬化功能後，Hyper-V 虛擬化平台中的 Hypervisor 虛擬化管理程序，將會完全掌控底層硬體伺服器的「虛擬化擴充功能」（Virtualization Extensions），並且防止其它軟體和上層 VM 虛擬主機內的客體作業系統使用，所以管理人員便無法在第一層主機的作業系統中，安裝和啟用 Hyper-V 虛擬化功能（如圖 4 所示）。
圖 4、舊版 Hyper-V 虛擬化平台不支援巢狀式虛擬化
現在，只要採用 Windows Server 2016 或後續版本，安裝並啟用 Hyper-V 虛擬化功能後，Hyper-V Hypervisor 虛擬化管理程序，便支援向上層 VM 虛擬主機公開並傳遞底層硬體輔助虛擬化技術。所以，第一層的 VM 虛擬主機內的客體作業系統，便能順利感知底層公開並傳遞而來的硬體輔助虛擬化技術，進而安裝和啟用 Hyper-V 虛擬化功能並建立第二層 VM 虛擬主機（如圖 5 所示），達成巢狀式虛擬化運作架構，也就是 VM 虛擬主機內可以再產生 VM 虛擬主機。
事實上，當 VM 虛擬主機採用 Windows 10 年度更新版本時，如同 Windows Server 2016 版本一樣，支援接收底層傳遞的硬體輔助虛擬化技術，達成巢狀式虛擬化運作架構。
圖 5、新版 Hyper-V 虛擬化平台完全支援巢狀式虛擬化
實戰 – Azure VM 啟用巢狀式虛擬化
在過去，企業和組織通常僅在內部資料中心內，組態設定和啟用 Hyper-V 虛擬化平台支援巢狀式虛擬化，然而從 Microsoft Build 2017 年大會中，微軟官方便正式宣佈 Azure 公有雲環境，新增「Dv3 和 Ev3」規模的 VM 虛擬主機，簡單來說這兩種新增的 VM 虛擬主機規模，支援啟用巢狀式虛擬化技術（如圖 6 所示）。
圖 6、Azure VM 虛擬主機支援巢狀式虛擬化運作架構示意圖
因此，管理人員即便在地端資料中心內，沒有額外的硬體資源情況下，無須準備任何硬體伺服器和網路交換器，也能透過建立 Azure VM 虛擬主機並啟用巢狀式虛擬化技術，輕鬆建構研發和測試環境，例如，建構 Azure Stack HCI、AKS on Azure Stack HCI……等，HCI 超融合叢集和 Kubernetes 叢集運作環境。
建立 Dv3 或 Ev3 的 Azure VM 虛擬主機
在本文實作環境中，建立一台「Standard D16s v3」（16 vCPU、64 GB vRAM）規模的 VM 虛擬主機，採用的客體作業系統為「Windows Server 2019 Datacenter」版本，在這樣的 VM 虛擬主機規模環境下，每小時大約花費新台幣「23 元」（如圖 7 所示）。
圖 7、部署 Standard D16s v3 規模的 VM 虛擬主機
此外，我們額外建立一台「Standard A8 v2」（8 vCPU、16 GB vRAM）規模的 VM 虛擬主機，同樣採用「Windows Server 2019 Datacenter」客體作業系統版本，以便稍後與 Standard D16s v3 規模 VM 虛擬主機進行對照了解差異。
啟用巢狀式虛擬化技術
首先，登入不支援巢狀式虛擬化技術的 Standard A8 v2 規模 VM 虛擬主機，雖然採用支援巢狀式虛擬化技術的 Windows Server 2019 客體作業系統，然而在嘗試安裝 Hyper-V 伺服器角色時，便會發現系統在檢查程序執行完畢後，便會出現「The processor does not have required virtualization capabilities」的錯誤訊息（如圖 8 所示）。
圖 8、無法順利安裝和啟用 Hyper-V 伺服器角色
此時，管理人員可以透過 Coreinfo 工具，檢查主機 CPU 處理器的各項指令集和硬體輔助虛擬化支援情況，此工具下載完畢並解壓縮之後，無須執行安裝程序即可直接在命令提示字元視窗中執行，請鍵入「coreinfo64.exe -v」指令，立即檢查在 Standard A8 v2 規模的 VM 虛擬主機中，CPU 處理器型號，以及是否擁有 Intel VT-x 及 EPT 硬體輔助虛擬化功能，從檢查結果中可以看到，Standard A8 v2 規模 VM 虛擬主機，並沒有獲得底層 Hyper-V 虛擬化平台傳遞的硬體輔助虛擬化功能，因此才會導致安裝和啟用 Hyper-V 伺服器角色時失敗（如圖 9 所示）。
圖 9、Standard A8 v2 規模 VM 虛擬主機，沒有支援相關硬體輔助虛擬化功能
同樣的情況，透過 Coreinfo 工具檢查 Standard D16s v3 規模的 VM 虛擬主機時，從檢查結果中可以看到，Standard D16s v3 規模的 VM 虛擬主機，確實獲得底層 Hyper-V 虛擬化平台傳遞的 Intel VT-x 及 EPT 硬體輔助虛擬化功能（如圖 10 所示），因此管理人員可以放心安裝和啟用 Hyper-V 伺服器角色。
圖 10、Standard D16s v3 規模 VM 虛擬主機，獲得 Intel VT-x 及 EPT 硬體輔助虛擬化功能
建立 NAT vSwitch 虛擬交換器
在前述「巢狀式虛擬化環境需求」小節中已經說明，由於在 Azure 公有雲環境中，管理人員無法碰觸到 Azure 公有雲基礎架構中底層的 Hyper-V 虛擬化平台。因此，必須建立 NAT vSwitch 虛擬交換器，以便稍後建立的第二層 VM 虛擬主機，能夠透過這個第一層 Hypervisor 虛擬化管理程序，所建立的 NAT vSwitch 虛擬交換器進行網路封包的路由。
在本文實作環境中，建立的 NAT vSwitch 虛擬交換器名稱為「NestedVM-NATSwitch」，屆時負責進行網路位址轉譯處理的 IP 網段為「10.10.75.0/24」，並且第二層 VM 虛擬主機指向的預設閘道 IP 位址為「10.10.75.1」。
請在順利安裝和啟用 Hyper-V 伺服器角色的 Azure VM 虛擬主機中，開啟 PowerShell 指令視窗並鍵入「New-VMSwitch -Name "NestedVM-NATSwitch" -SwitchType Internal」指令，以便建立給屆時第二層 VM 虛擬主機使用的 NAT vSwitch 虛擬交換器。
接著，執行「New-NetIPAddress -IPAddress 10.10.75.1 -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet（NestedVM-NATSwitch）"」指令，建立第二層 VM 虛擬主機使用的預設閘道 IP 位址「10.10.75.1」。最後，執行「New-NetNat -Name " NestedVM-NATSwitch" -InternalIPInterfaceAddressPrefix "10.10.75.0/24"」，指定 NAT 網路位址轉譯處理的 IP 網段為「10.10.75.0/24」。
上述建立 NAT vSwitch 虛擬交換器的動作完成後，分別執行「Get-VMSwitch」、「Get-NetIPAddress -IPAddress 10.10.75.1」、「Get-NetNat」指令，確認剛才組態設定內容是否正確無誤（如圖 11 所示）。
圖 11、檢查 NAT vSwitch 虛擬交換器組態設定內容
建立第二層 VM 虛擬主機
在前述「巢狀式虛擬化環境需求」小節中已經說明，管理人員必須確認 Hyper-V 虛擬化平台中，稍後建立的第二層 VM 虛擬主機組態設定版本支援「8.0」或後續版本，屆時才能順利為第二層 VM 虛擬主機啟用巢狀式虛擬化功能。
在本文實作環境中，Hyper-V 虛擬化平台為 Windows Server 2019 版本，請在 PowerShell 指令視窗中執行「Get-VMHostSupportedVersion」指令，確認目前 Hyper-V 虛擬化平台支援哪些 VM 虛擬主機組態設定版本，再次執行並加上參數「-Default」，查詢預設建立 VM 虛擬主機時採用哪個 VM 虛擬主機組態設定版本，在本文實作環境中將會採用最新的「9.0」VM 虛擬主機組態設定版本（如圖 12 所示）。
有關 VM 虛擬主機組態設定版本的詳細資訊，例如，必須採用 5.0 組態設定版本，才能支援 Windows Server 2012 R2 客體作業系統……等，請參考 Microsoft Docs – Supported Virtual Machine Configuration versions 文章內容。
圖 12、查詢 Hyper-V 虛擬化平台支援的 VM 虛擬主機組態設定版本
圖 13、第二層 VM 虛擬主機，停用動態記憶體功能並連接至 NAT vSwitch 虛擬交換器
在為第二層 VM 虛擬主機開機並安裝客體作業系統之前，還必須為第二層 VM 虛擬主機的 vCPU 處理器，執行啟用 vCPU 虛擬處理器硬體輔助虛擬化擴充功能的動作，屆時第二層 VM 虛擬主機才能正確接收到，由底層 Hyper-V 虛擬化平台所公開和傳遞而來的 Intel VT-x 及 EPT 硬體輔助虛擬化技術。
請在 PowerShell 指令視窗中執行「Set-VMProcessor -VMName Level2-VM -ExposeVIrtualizationExtensions $true」指令，為名稱為「Level2-VM」的第二層 VM 虛擬主機，啟用 vCPU 虛擬處理器硬體輔助虛擬化擴充功能的動作，順利啟用後請再次確認，「ExposeVirtualizationExtensions」欄位值是否為「True」確保啟用的工作任務已套用生效（如圖 14 所示）。
請注意，第二層 VM 虛擬主機必須在「關機」（Power Off）狀態，才能啟用 vCPU 虛擬處理器硬體輔助虛擬化擴充功能，倘若處於「開機」（Power On）狀態時指令執行將會遭遇失敗。
圖 14、為第二層 VM 虛擬主機啟用 vCPU 虛擬處理器硬體輔助虛擬化擴充功能
圖 15、第二層 VM 虛擬主機順利獲得 Intel VT-x 及 EPT 硬體輔助虛擬化功能
建立第三層 VM 虛擬主機
至此，我們已經從一開始建立 Azure VM 虛擬主機（擔任第一層 VM 虛擬主機的角色），進而為第二層 VM 虛擬主機啟用巢狀式虛擬化技術，讓管理人員只需要一台 Azure VM 虛擬主機，即可透過巢狀式虛擬化技術，產生許多第二層 VM 虛擬主機，建構企業和組織需要的研發和測試環境。
或許，有管理人員可能有這種想法，既然第二層 VM 虛擬主機已經獲得 Intel VT-x 及 EPT 硬體輔助虛擬化功能，那麼是否能建立第三層或第四層甚至第五層 VM 虛擬主機呢？ 答案是肯定的，只要第三層、第四層、第五層的 VM 虛擬主機，能夠滿足巢狀式虛擬化環境需求，那麼便可以達到 VM 虛擬主機再產生 VM 虛擬主機的目標。
請注意，雖然底層的硬體輔助虛擬化功能可以層層傳遞上去，但是每多出一層 Hyper-V 虛擬化層級時，整體的儲存效能便會下降，所以越上層的 VM 虛擬主機儲存效能將會越發低落。
如圖 16 所示，名稱為「NestedVM-Level1」的第一層 VM 虛擬主機，為一開始建立的 Azure VM 虛擬主機，而名稱為「Level2-VM」則是啟用巢狀式虛擬化的第二層 VM 虛擬主機，名稱為「Level3-VM」的 VM 虛擬主機，則是由第二層 VM 虛擬主機在啟用巢狀式虛擬化技術後，再產生的第三層 VM 虛擬主機。
圖 16、在 Azure VM 虛擬主機中透過巢狀式虛擬化，建立第三層 VM 虛擬主機
建構 HCI 超融合與 K8s 容器環境
在現代化敏捷基礎架構的浪潮下，企業和組織建構 HCI 超融合叢集和 Kubernetes 容器叢集環境的需求不斷升高。然而，管理人員在眾多廠商推出的產品中，又該如何簡單的搭建 PoC 概念性驗證環境，確保選擇的解決方案符合公司的需求並且能夠解決遭遇的痛點。
舉例來說，管理人員希望搭建微軟 Azure Stack HCI 超融合叢集運作環境，在最小雙節點的運作架構中，除了至少需要準備二台通過驗證並支援 Azure Stack HCI 的硬體伺服器之外，每台硬體伺服器至少要配置 2 顆 SSD 固態硬碟、4 顆 HDD 機械式硬體、1 張 10GbE 網路卡，此外也必須準備至少 1 台 10GbE 網路交換器和 10GbE 線材，才能夠建構 Azure Stack HCI 超融合叢集運作環境。
在一般情況下，企業和組織要擁有對應的硬體伺服器和相關零組件配置相對困難。此時，管理人員便可以透過巢狀式虛擬化技術，在地端資料中心內以一台硬體伺服器，建立多台第二層 VM 虛擬主機並啟用巢狀式虛擬化機制，進而搭建 Azure Stack HCI 超融合叢集運作環境。
有關搭建 Azure Stack HCI 超融合叢集環境的詳細作法，請參考本刊「 第 181 期 - 微軟超融合雲端作業系統 Azure Stack HCI 開箱 」技術專欄內容即可。
倘若，企業和組織在地端資料中心內，沒有多餘並且符合巢狀式虛擬化技術的硬體伺服器時，更可以直接在 Azure 公有雲環境中，選擇支援巢狀式虛擬化技術的 Azure VM 虛擬主機，輕鬆搭建 Azure Stack HCI 超融合叢集環境，甚至是 AKS on Azure Stack HCI 的 Kubernetes 容器叢集環境。
有關搭建 AKS on Azure Stack HCI 容器叢集環境的詳細作法，請參考本刊「第 183 期 - AKS on Azure Stack HCI 實戰部署」技術專欄內容即可。
結語
透過本文的深入剖析及實戰演練，相信管理人員已經了解 Hyper-V 虛擬化平台中，內建支援的巢狀式虛擬化技術所帶來的強大功能，不僅能夠提供容器更高的隔離安全性，同時在企業和組織內部資料中心硬體資源不足時，借助 Auzre 公有雲環境輕鬆建構研發和測試環境。