在 2022 年 VMware Explore 大會上，VMware 官方正式發佈最新 vSphere 8 版本。同時，從 vSphere 8 版本開始，VMware 官方採用新的版本發佈模型，分別稱為「初始可用性」（Initial Availability，IA）和「通用可用性」（General Availability，GA），簡單來說，新的版本發佈方式和 vSphere+ 雲端服務版本將保持一致。

首先，當 VMware 官方發佈 RC 和 RTM 發佈之後，將會採用和 GA 相同測試品質和發佈標準的流程，在「2 週」之後發佈 IA 版本，接著在「4 - 6 週」之後發佈 GA 版本，而無須像過去必須等待「6 個月」之久，才能取得帶有新功能和增強功能的版本（如圖 1 所示）。

目前，DPU 以 SmartNIC 的型態推出（如圖 3 所示），它的外型雖然和 PCIe 介面卡相同，但是 SmartNIC 內含 ARM CPU 處理器，和支援編譯功能的加速器，並且通常配置 10Gb 到 100Gb 的多個通訊埠，以及一個用於管理用途的乙太網路通訊埠，最重要的是 SmartNIC 有個本地端儲存資源，提供管理人員安裝軟體，例如，將 ESXi 虛擬化管理程序安裝於其中。

因此，透過裝置群組整合後的單一裝置，對於 VM 虛擬主機來說同樣只是新增一個單一 PCI Device 即可，並且配置裝置群組的這樣的 VM 虛擬主機，仍然支援 DRS VM Placement 機制，以及 vSphere HA 高可用性機制。

當管理人員為 VM 虛擬主機配置裝置群組時，在新增 PCI Device 作業流程中，系統將會顯示已經裝置群組後的狀態，如圖 8 所示，第一個 PCI 裝置便是二個 GPU 透過 NVLink 所組合，第二個 PCI 裝置則是 GPU 整合 NIC 的裝置。

在過去的版本中，一旦組態設定 VM 虛擬主機使用 DirectPath I/O 直連機制時，可以得到完全使用底層硬體裝置效能的好處，然而這個直連機制的副作用，便是導致 VM 虛擬主機喪失某些 vSphere 特色功能，舉例來說，這樣的 VM 虛擬主機無法執行 vSphere vMotion 進行遷移，也無法被 vSphere DRS 自動執行調度作業，更無法被 vSphere HA 高可用性機制所保護，此外也無法針對 VM 虛擬主機進行暫停作業，和針對 vMemory 記憶體及 vDisk 虛擬硬碟進行快照。

現在，最新的 vSphere 8 版本中，推出「虛擬裝置擴充模組」（Device Virtualization Extensions，DVX），是基於 Dynamic DirectPath I/O 技術之上，並為裝置廠商提供新的運作框架和 API。因此，底層的 ESXi 安裝 DVX 驅動程式，上層的 VM 虛擬主機使用支援 DVX 機制的虛擬裝置，達成高效能使用底層硬體的目的，同時又能保有 vSphere 特色功能，例如，透過 vSphere DRS 自動執行調度作業，並被 vSphere HA 高可用性機制所保護（如圖 9 所示）。

事實上，在 vSphere 7 版本時，便加入 vSphere with Tanzu 新特色功能，也就是將原有 vSphere 叢集，重新建構為支援容器工作負載的 Kubernetes 叢集，讓 ESXi 虛擬化平台成為 Kubernetes 容器平台的 Worker 節點，並在 ESXi 上直接運作容器 Pod。

同時，也推出支援有雲和公有雲部署的 TKG（Tanzu Kubernetes Grid），也就是支援企業和組織在地端資料中心內部署的 TKGs（Tanzu Kubernetes Grid Service for vSphere），以及部署至公有雲的 TKGm（Tanzu Kubernetes Grid Multi-Cloud）。

現在，最新的 vSphere 8 版本中，重新整合為統一的 Kubernetes 容器平台，無論是部署到地端資料中心或公有雲，都是採用同一套的 TKG 2.0 版本，並且加入新的「vSphere Zone」隔離機制，支援跨越多個 vSphere 叢集進行整合，以便獲得最大的可用性和資源，搭配來自 Cluster API 開放源始碼中的 ClusterClass 宣告機制，以便能夠管理人員能夠決定將容器部署成跨 vSphere 叢集，或是在各自的 vSphere 叢集中互相隔離工作負載（如圖 10 所示）。

對於 vSphere 基礎架構有管理經驗的人來說，一定知道整個 vSphere 運作架構的組態設定和統計資料，都是儲存在 vCenter Server 管理平台當中。雖然，統一式的集中管理有其優勢，然而碰上災難事件時卻有可能會產生盲點。

舉例來說，管理人員定期在「每天凌晨 3 點」為 vCenter Server 執行備份作業，但是 vCenter Server 卻在晚上 8 點時發生災難事件，此時即便立即為 vCenter Server 執行備份復原作業，但是從凌晨 3 點到晚上 8 點之間，仍然發生許多事件和各項工作負載的統計資料，因此復原後的 vCenter Server 管理平台，將會遺失這段期間的事件和統計資料。

在最新 vSphere 8 版本中，推出「分散式鍵值儲放區」（Distributed Key-Value Store，DKVS）機制，這項機制的設計原理，在於當 vCenter Server 管理平台發生災難時，事實上這段期間發生的事件和統計資料，也都儲存在 ESXi 主機當中。

因此，當 vCenter Server 管理平台進行災難復原後，與 vSphere 叢集中的眾多 ESXi 節點主機進行溝通，並將災難發生至上次備份時間期間的事件和統計資料取回，讓 vCenter Server 管理平台能夠迅速恢復，並且取得 vSphere 叢集和 ESXi 節點主機的最新資訊（如圖 11 所示）。

在 vSphere 虛擬化基礎架構中，對於工作負載的記憶體使用量和監控機制，一直是 VMware 努力增強和改進的方向，以便能夠承載更多的工作負載於 vSphere 架構中。從 vSphere 7 U3 版本開始，推出「vSphere 記體體監控和修復」（vSphere Memory Monitoring and Remediation，vMMR）機制。

現在，最新 vSphere 8 版本中，將原有 vMMR 記體體監控和修復增強至 vMMR v2版本（如圖 12 所示），透過更智慧的記憶體監控和修復機制，有效增強 vSphere DRS 自動化調度工作負載，讓 VM 虛擬主機和容器等工作負載，能夠在最佳化的 DRS 調度決策中得到最充足的資源，確保 VM 虛擬主機和容器內的營運服務得到最佳效能和各項資源。

在過去的 vSphere 版本中，雖然 vMotion 線上遷移機制，能夠滿足絕大多數應用程序的需求，並且在遷移過程中和遷移後，對於應用程式都是無縫且透過的遷移，並不會對應用程式造成任何影響。

然而，對於某些「時間敏感應用程式」（Time-Sensitive Application）、VoIP、叢集服務等，可能會產生不良的影響，舉例來說，可能在執行 vMotion 遷移期間導致 VoIP 掉線，或者是觸動到叢集服務的心跳機制，導致引發容錯移轉叢集切換的動作。

因此，在 vSphere 8 版本中推出「vMotion 通知」（vMotion Notifications）機制，能夠針對這些特定的應用程式進行通知後才遷移，確保應用程式準備完畢後才進行遷移的動作。下列為 VM 虛擬主機執行 vMotion 通知時的執行步驟（如圖 13 所示）：

1. 管理人員為 VM 虛擬主機執行 vMotion 線上遷移。

2. VM 虛擬主機中的應用程式，收到 vMotion 遷移程序開始執行的通知。

3. 應用程式開始準備 vMotion 遷移作業。

4. 應用程式發送「確認」（Acknowledgement）訊息，給 vMotion 遷移程序確認可以開始執行遷移作業。

5. 系統透過 vMotion 機制線上遷移 VM 虛擬主機至別台 ESXi 節點主機。

6. 應用程式收到 vMotion 遷移程序通知遷移作業已完成。

在過去的 vSphere 版本中，不斷增強和提升 vSphere vMotion 線上遷移的能力，讓企業和組織在需要遷移運作中的 VM 虛擬主機工作負載時，無論是遷移運算資源的 vSphere vMotion，或是遷移儲存資源的 vSphere Storage vMotion 機制，都能以最快的速度完成線上遷移作業，避免 VM 虛擬主機中的營運服務產生任何卡頓甚至中斷的情況。

然而，有些管理人員可能發現，透過 vSphere vMotion 機制線上遷移運作中的 VM 虛擬主機時，確實能夠在最短時間內遷移完成，倘若是遷移「關閉」（Power Off）的 VM 虛擬主機，尤其是配置大容量儲存空間時，那麼遷移時間將需要很長時間，甚至同樣的遷移情境，將 VM 虛擬主機「開機」（Power On）後進行遷移，反而遷移時間縮短許多，為何會有這種遷移時間差異的情況出現 ？

主要原因在於，「線上遷移」（Hot Migration）的執行程序、I/O 同步機制、傳輸效能，都與「離線遷移」（Cold Migration）不同所導致，舉例來說，VM 虛擬主機運作中執行遷移時採用的 Hot Migration，將會採用最佳化後的「多執行緒」（Multi-Thread），與 ESXi 節點主機的多核心協同運作，傳輸效能最高可達 80Gbps。

反觀 VM 虛擬主機關閉時執行遷移採用的 Cold Migration，採用的則是「網路文件複製」（Network File Copy，NFC）通訊協定，並且僅採用「單執行緒」（Single-Thread），僅使用 ESXi 節點主機的單顆核心進行運算，傳輸效能最高僅能到達 1.3Gbps（如圖 14 所示）。

在新版 vSphere 8 當中，採用「統一資料傳輸」（Unified Data Transport，UDT）機制，來處理 Cold Migration 遷移的 VM 虛擬主機傳輸作業。一旦 VM 虛擬主機關閉並且觸發 Cold Migration 遷移作業時，系統將會以原有的 NFC 通訊協定為「控制通道」（Control Channel），而「資料傳輸」（Data Transfer）的部份則會改採 vSphere vMotion 通訊協定，以便提升傳輸效能和傳輸速度節省大量時間。

值得注意的是，有些管理人員會忽略 ESXi 節點主機的 VMkernel Port 組態設定，進而造成傳輸速度上異常緩慢，舉例來說，管理人員並未將 ESXi 節點主機的傳輸流量類型隔開，將 Management 和 vMotion 流量類型混用，而一般來說 Management 管理網路可能只有 1Gbps 的傳輸速度，因此執行 Migration 遷移作業時便導致傳輸效率不彰。

又或者是，已經將實體網路和 ESXi 節點主機的傳輸流量類型隔開，但是在組態設定上卻忽略 VMkernel Port 的部份，未將原有共用 Management 網路的 vMotion 取消勾選，造成 Migration 遷移作業時仍舊使用 Management 慢速網路進行傳輸（如圖 15 所示）。

首先，在此實作中率先測試使用傳統 NFC 通訊協定進行 Cold Migration，針對這樣的 VM 虛擬主機配置將其關機之後進行遷移，觀察將會花費多少傳輸時間。

目前，測試的「UDT-TestVM」虛擬主機運作於 Node02 節點主機上，在 vCenter 管理介面中，依序點選「UDT-TestVM > Actions > Migrate」，在彈出的 Migration 互動視窗中，選擇「Change both compute resource and storage」選項後，按下 Next 鈕繼續 Cold Migration 流程（如圖 18 所示）。

在 2. Select a compute resource 頁面中，選擇要將 UDT-TestVM 虛擬主機運算資源，遷移至虛擬化基礎架構中哪一台 ESXi 主機，在本文實作環境中選擇「node01.lab.weithenn.org」，並確認下方相容性檢查結果為「Compatibility checks succeeded.」後按下 Next 鈕。

在 3. Select storage 頁面中，選擇要將 UDT-TestVM 虛擬主機儲存資源，遷移至虛擬化基礎架構中哪一個 Datastore 中，在本文實作環境中選擇「Node01-datastore」，此時在下方相容性檢查結果，將會警告管理人員「This can lead to lower network copy throughput.」，目前的傳輸網路吞吐量不佳的警告訊息，但是仍然能夠按下 Next 鈕繼續遷移流程。

在 4. Select networks 頁面中，選擇 UDT-TestVM 虛擬主機虛擬網路，是否要連接至不同的 vSwitch 虛擬網路交換器或 Port Group 連接埠群組，在本文實作環境中採用預設值即可。最後，在 5. Ready to complete 頁面中，確認相關資訊無誤後按下 Finish 鈕，便立即執行 NFC 通訊協定的 Cold Migration 遷移作業。

此時，可以在 vCenter 管理介面下方 Recent Tasks 區塊，看到 Cold Migration 遷移作業的執行進度，或是切換到「Cluster > Monitor > Tasks and Events > Tasks」，查看更詳細的 Cold Migration 遷移作業內容，從結果中可以看到此次採用傳統 NFC 通訊協定的遷移作業花費「6 分 12 秒」（如圖 19 所示）。

在使用新式 UDT 機制進行 Cold Migration 遷移之前，必須先為來源端和目的端的 ESXi 節點主機，針對 VMkernel Port 進行組態設定，才能確保稍後使用 Cold Migration 遷移作業時，使用新式的 UDT機制，而非傳統的 NFC通訊協定進行資料傳輸。

請在 vCenter 管理介面中，依序點選「ESXi Host > Configure > Networking > VMkernel adapters > Edit」，在 VMkernel Port 組態設定視窗中，勾選「Provisioning」項目後按下 OK 鈕（如圖 20 所示）。

確保來源端和目的端的 ESXi 節點主機，都已經為遷移網路的 VMkernel Port 啟用「Provisioning」類型後，同樣的遷移情境，此時的 UDT-TestVM 虛擬主機，將從剛才的 Node01 遷移回 Node02，並觀察遷移作業時間與剛才傳統的 NFC 通訊協定有何不同。

請在 vCenter 管理介面中，依序點選「UDT-TestVM > Actions > Migrate」，在彈出的 Migration 互動視窗中，選擇「Change both compute resource and storage」選項後，按下 Next。在 2. Select a compute resource 頁面中，選擇要將 UDT-TestVM 虛擬主機運算資源，遷移至虛擬化基礎架構中哪一台 ESXi 主機，在本文實作環境中選擇「node02.lab.weithenn.org」，並確認下方相容性檢查結果無誤後按下 Next 鈕。

在 3. Select storage 頁面中，選擇要將 UDT-TestVM 虛擬主機儲存資源，遷移至虛擬化基礎架構中哪一個 Datastore 中，在本文實作環境中選擇「Node02-datastore」，此時在下方相容性檢查結果，並不會像剛才實作 NFC 通訊協定時產生警告訊息，而是通過相容性檢查的「Compatibility checks succeeded.」訊息（如圖 21 所示），請按下 Next 鈕繼續遷移流程。

在 4. Select networks 頁面中，選擇 UDT-TestVM 虛擬主機虛擬網路，是否要連接至不同的 vSwitch 虛擬網路交換器或 Port Group 連接埠群組，在本文實作環境中採用預設值即可。最後，在 5. Ready to complete 頁面中，確認相關資訊無誤後按下 Finish 鈕，便立即執行採用新式 UDT 機制的 Cold Migration 遷移作業。

同樣的，在 vCenter 管理介面下方 Recent Tasks 區塊，看到 Cold Migration 遷移作業的執行進度，或是切換到「Cluster > Monitor > Tasks and Events > Tasks」，查看更詳細的 Cold Migration 遷移作業內容，從結果中可以看到改採新式 UDT 機制的遷移作業僅花費「39 秒」便遷移完成（如圖 22 所示）。