本文將深入剖析vCenter Converter的運作原理，並藉由實作演練過程進行詳細解說，幫助管理人員將實體主機或其他虛擬化平台的VM虛擬主機，透過P2V或V2V轉換作業的方式，運作於企業或組織內的vSphere虛擬化平台之中。
在2022年2月時，VMware官方正式說明在產品下載清單中已經將舊版vCenter Converter版本徹底移除，主要原因在於最後一版的vCenter Converter發佈於2018年5月，並且官方支援至2019年12月就已經正式結束，所以基於vSphere虛擬化環境中整體工作負載的安全性和穩定性考量，便正式將舊版vCenter Converter版本移除。
然而，在當時的移除說明中，卻有補充說明vCenter Converter更新版本的開發工作已經在進行當中，但並未承諾正式發佈的時間，僅說明屆時推出的vCenter Converter更新版本，除了具備安全性和穩定性外，也將支援新世代版本的vSphere虛擬化平台。幸運的是，經過半年，VMware在社群論壇中發佈更新的vCenter Converter Beta版本後，立即在一週內便獲得超過1,500名使用者註冊，並且在2022年10月發佈vCenter Converter 6.3正式版本，與過去舊版相同的是支援「實體機轉虛擬機」（Physical to Virtual，P2V）、「虛擬機轉虛擬機」（Virtual to Virtual，V2V）等等特色功能，並且支援主流vSphere 7虛擬化平台以及最新Windows Server 2022 Hyper-V虛擬化平台進行轉換作業，如圖1所示。
圖1 VMware vCenter Converter運作架構示意圖 （圖片來源：vCenter Converter: P2V Virtual Machine Converter | VMware）
vCenter Converter運作架構說明
接著，說明新vCenter Converter的運作架構。
來源端主機為Windows作業系統時
在vCenter Converter運作架構中，便是透過「熱複製」（Hot Cloning）技術，將運作中的來源端Windows主機，線上即時複製傳輸資料至vSphere虛擬化平台，以及重新組態設定後完成轉換作業。
vCenter Converter支援轉換，安裝在實體機或VM虛擬主機中的Windows作業系統，支援的版本為客戶端的Windows 8.1/10/11，以及伺服器端的Windows Server 2012/2012R2/2016/2019/2022版本。
在開始執行轉換作業之前，先確保vCenter Converter主機、來源端Windows主機、目的端vSphere虛擬化平台之間，已經開啟並允許相關防火牆連接埠網路流量能夠通行，請開啟TCP Port 139, 443, 445, 902, 9089、UDP Port 137, 138，詳細資訊請參考VMware KB 1010056知識庫文章內容。
值得注意的是，若來源端Windows主機使用NetBIOS的話，則無須允許TCP Port 445通過防火牆，倘若未使用NetBIOS的話，則無須允許TCP Port 139、UDP Port 137, 138通過防火牆。
當轉換的來源端主機為Windows作業系統時，將會執行三個轉換程序。首先，擔任vCenter Converter角色的主機將會為來源端主機準備P2V或V2V轉換作業，並在準備過程中透過取得的管理者帳號及密碼，為來源端主機Windows作業系統中安裝Converter Standalone Agent代理程式，以便屆時能夠針對來源端主機的磁碟分割區，進行快照後執行資料傳輸作業，如圖2所示。
圖2 轉換來源端主機為Windows作業系統時，第一個轉換程序工作任務。 （圖片來源：Using VMware vCenter Converter Standalone 6.3 - vCenter Converter Standalone 6.3）
第二個轉換程序工作任務是，vCenter Converter主機會連線至目的端vSphere虛擬化平台，透過取得的vCenter Server管理權限，建立和註冊VM虛擬主機，並觸發來源端主機的代理程式，將來源端主機的磁碟分割區進行快照，複製並傳輸到目的端主機當中，如圖3所示。
圖3 第二個轉換程序工作任務，來源端建立磁碟區快照後傳輸至目的端。 （圖片來源：Using VMware vCenter Converter Standalone 6.3 - vCenter Converter Standalone 6.3）
值得注意的是，如果「啟動」代理伺服器模式，則傳輸流量會先回到vCenter Converter主機，再傳送至目的端主機，若是「停用」代理伺服器模式，則傳輸流量將直接從來源端主機傳送至目的端主機。
第三個轉換程序工作任務是，當資料傳輸作業完成後，代理程式將安裝VM虛擬主機作業系統所需要的相關驅動程式，並且執行客製化組態設定，例如V2V轉換作業完成後將來源端主機中的代理程式移除等等，如圖4所示。
圖4 轉換作業最後工作任務，安裝相關驅動程式和客製化組態設定。 （圖片來源：Using VMware vCenter Converter Standalone 6.3 - vCenter Converter Standalone 6.3）
來源端主機為Linux作業系統時
vCenter Converter支援轉換，安裝在實體機或VM虛擬主機中的Linux作業系統，支援的發行版本為CentOS 6.x/7.x、RHEL 6.x/7.x、Ubuntu 14.04/16.04。
與轉換Windows作業系統不同，當轉換的來源端主機為Linux作業系統時，僅會執行二個轉換程序，主要差別在於轉換Windows作業系統時，vCenter Converter主機會在來源端主機安裝代理程式，而轉換Linux作業系統時，則不會在來源端主機安裝任何代理程式。
在開始執行轉換作業之前，先確保vCenter Converter主機、來源端Linux主機、目的端vSphere虛擬化平台之間，已經開啟並允許相關防火牆連接埠網路流量能夠通行，請開啟TCP Port 22, 443, 902，詳細資訊請參考VMware KB 1010056知識庫文章內容。
第一個轉換程序工作任務是，首先擔任vCenter Converter角色的主機經由流程中取得的SSH連線管理者帳號及密碼，確認能夠與來源端主機通訊後，透過vCenter Converter主機內包含的ISO映像檔，在目的端vSphere虛擬化平台中部署一台「輔助轉換虛擬主機」（Helper Virtual Machine），以便在稍後的轉換過程中擔任中介容器的角色，如圖5所示。
圖5 SSH連線來源端主機並在目的端部署輔助轉換虛擬主機。 （圖片來源：Using VMware vCenter Converter Standalone 6.3 - vCenter Converter Standalone 6.3）
輔助轉換虛擬主機順利部署並啟動後，將會透過SSH連線至來源端主機，並將管理人員選擇要轉換的磁碟區進行複製傳輸作業，當磁碟區資料傳輸作業完成後，執行重新組態設定工作任務。當轉換程序完成，vCenter Converter主機便會在目的端vSphere虛擬化平台中關閉及刪除輔助轉換虛擬主機，如圖6所示。
圖6 執行來源端主機磁碟區資料傳輸和重新組態設定作業。 （圖片來源：Using VMware vCenter Converter Standalone 6.3 - vCenter Converter Standalone 6.3）
支援的虛擬化平台版本
在最新版本的vCenter Converter運作架構中，支援轉換來源端的企業等級虛擬化平台版本包括Hyper-V 2012 R2/2016/2019/2022，使用者等級的虛擬化版本，則支援Hyper-V 10/11、VMware Workstation 16.x和VMware Fusion 12.x。
至於支援轉換目的端的vSphere虛擬化平台，則是vSphere 6.5/6.7/7.0版本。雖然官方並未條列支援最新的vSphere 8.0，但是本文實戰演練中，採用的便是最新的vSphere 8.0版本，並且順利完成Windows Server 2022虛擬化平台中，VM虛擬主機的轉換作業。
實戰V2V轉換Hyper-V虛擬主機
在實戰演練中，來源端為Windows Server 2022 Hyper-V虛擬化環境，在Hyper-V虛擬化環境中，已經部署並運作一台Windows Server 2022作業系統的VM虛擬主機，該VM虛擬主機已經安裝和啟用IIS網頁伺服器，並且加入至「lab.weithenn.org」網域環境，至於VM虛擬主機連接的Hyper-V虛擬交換器名稱為「VMs-vSwitch」，如圖7所示。
圖7 Hyper-V虛擬化平台中的VM虛擬主機。
目的端則是最新的vSphere 8.0虛擬化環境，稍後便是將Hyper-V虛擬化環境的VM虛擬主機，透過vCenter Converter的「熱複製」（Hot Cloning）技術，將運作中的VM虛擬主機線上即時複製，並傳輸至vSphere虛擬化平台。
V2V Hot Cloning – Windows Server 2022
在實作環境內，於Windows 10主機中，安裝最新發佈的vCenter Converter 6.3.0版本。開啟vCenter Converter工具後按下〔Convert machine〕按鈕，在彈出的精靈對話視窗中，於Source System頁面選擇準備轉換的來源端主機為開機中或是關機中，以及遠端主機為Windows或Linux作業系統，或者是準備轉換的主機為本機系統。
在本文實作中，準備轉換Hyper-V虛擬化平台內運作中的VM虛擬主機，因此選擇「Powered On」和「Remote Windows machine」項目，並在下方來源端主機資訊中填入主機名稱和管理者帳號及密碼，本文實作主機名稱為「ws2022-web01」，管理者帳號是「lab.weithenn.org\Administrator」。確認無誤後按下「View source details」，此時vCenter Converter主機將會嘗試連結來源端主機，如圖8所示。
圖8 vCenter Converter主機連接至準備轉換作業的來源端主機。
一旦連結來源端主機成功，將會出現vCenter Converter Standalone代理程式部署選項，因為在轉換過程中必須為來源端主機安裝代理程式，所以讓管理人員選擇當轉換作業成功時要如何處理代理程式，可以選擇轉換作業成功後自動移除代理程式，或是之後手動移除代理程式，本文實作選擇「Automatically uninstall the files when import succeeds」項目，選擇完畢後系統便會為來源端主機安裝vCenter Converter Standalone代理程式。
順利為來源端主機安裝代理程式後，便會顯示來源端主機的詳細資訊，包括作業系統版本、記憶體空間、網路卡資訊、系統分割區等等，確認無誤後，按下〔Next〕按鈕進入下一個步驟。
在Destination System頁面中，Destination type下拉式選單中選擇VMware Infrastructure virtual machine項目，表示目的端為vSphere虛擬化環境，如果目的端為VMware Workstation或Fusion客戶端虛擬化環境時，則選擇其他項目。
在下方目的端主機資訊中，填入主機名稱和管理者帳號及密碼，本文實作主機名稱是「vcenter8」，管理者帳號為「Administrator@lab.weithenn.org」，確認後按下〔Next〕按鈕，便會連接至vCenter Server管理平台，成功連結後將出現憑證資訊，確認後便進入下一個轉換作業程序。
在Destination Virtual Machine頁面中，會顯示來源端主機的FQDN名稱，以及剛才連結成功的vCenter Server管理平台，管理人員選擇要將轉換後的VM虛擬主機放置於哪個儲存容器當中，本文實作環境放置於名稱為「V2V-VMs」的資料夾內，如圖9所示。
圖9 將屆時V2V轉換後的VM虛擬主機存放於V2V-VMs資料夾內。
在Destination Location頁面中，先選擇轉換後的VM虛擬主機要運作在哪個vSphere Cluster和ESXi虛擬化平台中，右側上方的Datastore下拉式選單中，則是選擇V2V轉換後的VM虛擬主機所要使用的Datastore儲存資源，右側下方的Virtual machine version下拉式選單中，為選擇V2V轉換後的VM虛擬主機，使用的VM虛擬主機虛擬硬體版本，本文實作環境中採用最新的ESXi 8虛擬化平台，所以選擇採用最新的「Version 20」版本，如圖10所示。
圖10 選擇V2V轉換後的VM虛擬主機運算和儲存資源及虛擬硬體版本。
在Options頁面中，可以針對V2V轉換後的VM虛擬主機內容進行調整，舉例來說，來源端的VM虛擬主機原本配置2 vCPU和8GB vRAM，但是在此頁面中卻變成僅配置1 vCPU和1GB vRAM，管理人員便能按下〔Edit〕進行組態設定修改作業。
值得注意的是，VM虛擬主機連接的vSwitch虛擬交換器組態設定，原本來源端VM虛擬主機，在Hyper-V虛擬化環境中連接至「VMs-vSwitch」，但是在vSphere虛擬化環境中並沒有這個名稱的vSwitch虛擬交換器，在本文實作中便將來源端VM虛擬主機改為連接至vSphere虛擬化環境中名稱為「V2V-vNetwork」的連接埠群組，並且採用與vSphere虛擬化平台深度結合的「VMXNET3」網路卡控制器，如圖11所示。
圖11 選擇連接的vSwitch虛擬交換器連接埠群組和網路卡控制器類型。
在Advanced options選項中，管理人員可以啟用其中的資料同步設定，在V2V轉換作業完成後，由於轉換期間來源端主機的各項資料，有可能發生新增、修改、刪除等情況，啟用資料同步機制可以在V2V轉換作業完成後觸發資料同步設定。此外，還可以設定V2V轉換作業完成後，是否要將來源端主機關機，或是目的端主機自動開機，以及安裝VMware Tools等等動作，管理人員可以依據運作環境需求自行調整，如圖12所示。
圖12 組態設定V2V轉換作業完成後，自動幫VM虛擬主機安裝VMware Tools。
在Summary頁面中，檢查各項組態設定值是否正確無誤，確認後按下〔Finish〕按鈕，系統便立即開始執行V2V轉換作業。在vCenter Converter工具視窗中，點選下方的Task progress頁籤，將會看到V2V轉換作業的詳細資訊，同時也可以看到轉換進度和系統預估剩餘的轉換時間，如圖13所示。
圖13 開始V2V轉換作業並查看相關資訊。
此時，也可以同步切換至vCenter Server管理介面，點選下方的Recent Tasks頁籤，就會看到vCenter Converter主機已經透過剛才鍵入的vCenter Server管理者帳號密碼資訊連接至vCenter Server管理平台，並且新增和註冊V2V虛擬主機，如圖14所示。
圖14 vCenter Converter順利新增和註冊V2V虛擬主機。
經過一段轉換和傳輸時間之後，V2V轉換作業順利完成，可以點選Summary頁籤，查看V2V轉換時來源端Hyper-V虛擬主機資訊，以及V2V轉換後目的端vSphere虛擬主機資訊，以及自訂重新組態設定的部分，例如V2V轉換成vSphere虛擬主機後，系統直接安裝VMware Tools並顯示完成工作任務，如圖15所示。
圖15 順利完成V2V轉換作業。
測試V2V虛擬主機能否正常運作
一般情況下，即便V2V轉換完成後，也不應該冒然地直接將轉換後的vSphere虛擬主機開機，舉例來說，在本文實作環境中，Hyper-V虛擬化平台中的VM虛擬主機仍開機中，如果直接將vSphere虛擬化平台中的VM虛擬主機開機，那麼將會發生IP位址和電腦名稱衝突的情況。
此外，因為VM虛擬主機運作在不同的虛擬化平台，所以網路卡類型重新組態設定過，因此網路卡MAC位址也會不同，如果立即將來源主機直接關機，將會發現目的端主機發生問題，主要原因在於底層網路交換器和路由器必須重新學習這個新出現的網路卡MAC位址，在學習到之前都很有可能發生網路連線不正常的情況。
因此，建議先將轉換後的vSphere VM虛擬主機，設定成網路卡連線功能取消，確認VM虛擬主機是否能夠順利開機、VMware Tools是否正確運作、IIS網頁伺服器服務是否正常運作等等。在vCenter管理介面中，點選該台VM虛擬主機並且編輯設定，在Virtual Hardware頁籤中展開Network Adapter選單，取消勾選「Connect At Power On」選項，再按下〔OK〕按鈕套用生效，如圖16所示。
圖16 取消勾選Connect At Power On選項，停用VM虛擬主機網路卡。
順利開機後，雖然已經將VM虛擬主機網路卡功能停用，但仍能採用lab.weithenn.org網域管理者帳號登入，主因在於V2V轉換作業剛完成，尚能透過網域登入快取機制順利登入系統，成功登入系統後，確認相關系統組態設定是否正常、VMware Tools服務是否啟動，以及本文實作的IIS網頁伺服器服務是否正常啟動。
開啟命令提示字元，鍵入「netstat -na | find ":80"」指令，檢查IIS網頁伺服器服務是否Listen TCP Port 80，然後開啟瀏覽器在網址列鍵入「http://localhost/」，透過連結Loopback的方式查看IIS網頁內容，如圖17所示。
圖17 檢查IIS網頁伺服器服務是否Listen TCP Port 80並查看IIS網頁內容。
回到vCenter管理介面中，可以看到VM虛擬主機作業系統版本順利辨識，並且VMware Tools運作正常，如圖18所示，雖然IP位址顯示169.254.x.x，主因便是停用VM虛擬主機網路卡連線導致，確認VM虛擬主機連接的vSwitch連接埠群組，以及相關組態內容無誤後，便可以將VM虛擬主機關機。 確認V2V轉換後的VM虛擬主機運作無誤，便可以在安排的維護時間中，讓來源端Hyper-V虛擬化平台中的VM虛擬主機關機，將vSphere虛擬化平台中的VM虛擬主機開機，如果希望能夠減少底層網路交換器和路由器重新學習VM虛擬主機的MAC位址時間，可以重新組態設定VM虛擬主機MAC位址。
圖18 透過vCenter管理介面確認VM虛擬主機組態設定。
舉例來說，本文實作環境來源端Hyper-V虛擬化平台VM虛擬主機，其MAC位址為「00:15:5D:4B:24:00」，在vCenter管理介面中，點選該台VM虛擬主機並編輯設定，在Virtual Hardware頁籤中展示Network adapter選單，勾選「Connect At Power On」選項。在MAC Address欄位，將預設值Automatic改為「Manual」，然後鍵入MAC位址「00:15:5D:4B:24:00」，確認無誤再按下〔OK〕按鈕套用生效，如圖19所示。
圖19 啟用網路卡連線功能並設定MAC位址。
成功開機並順利登入後，可以看到這台VM虛擬主機，除了能順利透過DC網域控制站、查詢DNS記錄之外，也能透過FQDN順利連接IIS網頁伺服器服務，如圖20所示。
圖20 V2V轉換後的VM虛擬主機，重新回到企業網路繼續服務。
至此，V2V轉換作業順利完成，將原本運作於Hyper-V虛擬化平台中的VM虛擬主機，轉換為vSphere虛擬化平台的VM虛擬主機後繼續運作。
IP位址已被Hyper-V Network Adapter佔用？
如果管理人員發現IP位址變成DHCP自動取得，嘗試組態設定回原有的固定IP位址時，Windows作業系統卻出現資訊提示視窗，說明組態設定的固定IP位址已經被先前的Microsoft Hyper-V Network Adapter虛擬網路卡所使用，如圖21所示。
圖21 系統顯示原有固定IP位址已被先前的Hyper-V網路卡所使用。
雖然可以按下〔Yes〕按鈕強制設定，但也將為系統埋下日後不穩定的因素，那麼該如何解決這個問題？
請開啟裝置管理員，並展開Network Adapters選項，將會發現系統並沒有顯示剛才說明的Microsoft Hyper-V Network Adapter。點選上方「View > Show hidden devices」之後，再次查看，便會顯示Microsoft Hyper-V Network Adapter，點選右鍵選擇【Uninstall device】，讓系統移除這個裝置，因為這台VM虛擬主機已經完全運作在vSphere虛擬化平台中，不再需要Hyper-V虛擬網路卡，如圖22所示。
圖22 移除Microsoft Hyper-V Network Adapter網路卡。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞