ESXi主機是vSphere架構中運行虛擬機器的基礎，在獨立主機的運行及整合vCenter Server進階架構上皆提供完善的功能與管理工具，然而從測試環境到正式環境的部署，過程中可能會出現許多的疑問，因此本文特別整理出幾個ESXi主機部署與管理上的問題。
現今在IT市場上已有許多的虛擬化平台可供選擇，從免費的開源方案到付費的商用方案通通都有，不過若以目前企業IT的主流方案來看，基本上可區分為Microsoft Hyper-V與VMware vSphere。實務上選擇採用VMware vSphere的優點在於，無論是打算安裝獨立運行的ESXi主機，還是整合vCenter Server來享有集中管理與各項高可用性（如HA、FT、DRS）以及vSAN等強大功能，除了運行相當快速與穩定外，在各類管理工具的操作設計上也容易上手。其次，在技術資源部分，也是目前眾多虛擬化平台中最為豐富，這個優勢對於IT人員更是極為重要。
在眾多企業客戶中，採用獨立ESXi主機或是整合vCenter Server架構的皆有。儘管採用整合vCenter Server的運行架構，已是普遍建議的部署方式，但對於一些中小型的IT環境而言，由於實際需要的虛擬機器並不多，因此初期只要在伺服器硬體的規劃上有完善的保護措施，例如磁碟陣列RAID 6、熱備援磁碟、雙電源供應器、不斷電系統、虛擬機器備份計畫等等，一樣可以部署出一個令人安心與滿意的優質虛擬化平台。
等到未來企業逐漸擴大營運規模後，同樣能夠無縫隙地進行升級並添加更多ESXi主機、虛擬機器、儲存設備、網路設備，並開始整合vCenter Server的集中管理機制，還可進一步啟用HA、FT、DRS、vSAN等先進虛擬化功能，以因應業務的成長所帶來的更多應用服務需求。
不管是選擇獨立的ESXi主機安裝，還是直接部署在vCenter Server的架構中，從測試階段到正式上線階段肯定都會有不少疑問與難題，有鑑於此，在接下來的實戰講解中，將引領大家一同來學習幾個常見的問題與解決方法。
在VMware Workstation Player安裝ESXi 7
在測試的環境中，很多IT人員會選擇將vSphere ESXi 7.0部署在已退役的主機內。然而，實際上這樣的部署方式，對於測試環境而言似乎太麻煩了一些，其實只要善用一台實體主機，無論其作業系統是Windows還是Linux，只要硬體資源充足，就可以運行多台ESXi主機的虛擬機器進行測試，甚至還能夠部署出整合vCenter Server與vSAN的進階架構
如何辦到的呢？很簡單，只要有VMware Workstation Pro或VMware Workstation Player即可。前者擁有最完善個人電腦的虛擬化管理功能，後者則僅提供基礎的操作功能，不過提供了非商用的免費授權。圖1所示便是VMware Workstation Pro 6.x版本，在新增虛擬機器時的選項設定中，若客體作業系統選取了「VMware ESX」，便可以進一步在「Version」欄位內挑選【VMware ESXi 7 and later】，開始安裝ESXi系統。
圖1 VMware Workstation Pro 6新增虛擬機器。
儘管VMware Workstation Pro功能強大，但對於中小企業的IT來說，通常還是會選擇價格更加便宜的VMware Workstation 16 Player以上版本來測試ESXi主機功能。然而，可能會發現在新增虛擬機器的過程中，找不到ESXi 7客體作業系統的選項，怎麼辦呢？其實只要到設定安裝映像的頁面中，如圖2所示，先選取「Installer disc image file (iso)」設定，再按下〔Browse〕按鈕來載入ESXi 7的映像，就會出現「VMware ESXi 7 and later detected」提示訊息，繼續按下〔Next〕按鈕，即可順利安裝ESXi主機並開機。
圖2 載入VMware ESXi安裝映像。
如圖3所示，便是成功透過VMware Workstation 16 Player完成ESXi主機安裝的DCUI（Direct Console User Interface）操作介面，可繼續按下〔F2〕鍵來完成各項系統配置與網路配置。若需要關機或重新開機，則選擇按下〔F12〕鍵，或者直接從「Player」功能選單中點選【Power】，再選擇【Shut Down Guest】或【Restart Guest】即可。
圖3 成功安裝ESXi 7.0。
將ESXi 7安裝在USB磁碟運行
想要測試最新ESXi系統的做法有很多種，常見的除了將其安裝在較老舊的實體主機來運行，或是選擇安裝在現行虛擬化平台的虛擬機器中進行測試外，還有最特別的第三種選擇，那就是把它安裝在USB行動磁碟中做測試，這樣的好處是不占用實體電腦的儲存空間，還可以任意安插到其他支援USB開機的電腦來啟動，只要此電腦的硬體規格能滿足ESXi系統的基本運行要求即可。
關於將ESXi 7.0系統安裝在USB磁碟的方法大致有兩種，第一種是先將ESXi 7.0安裝映像寫入至DVD並完成開機，然後在安裝過程中選擇將系統安裝在所安插的USB磁碟中，第二種做法是使用VMware Workstation的虛擬機器安裝方式來建立ESXi系統至USB磁碟中。
接下來要操作示範的是使用VMware Workstation虛擬機器的做法。首先，在「File」選單中點選【New Virtual Machine】，準備新增一個虛擬機器。在「Guest Operating System Installation」頁面中，可以選擇載入ESXi 7.x的安裝映像（ISO），或是稍後再修改設定也可以。按下〔Next〕按鈕，繼續下一步驟。
然後，在「Select a Guest Operating System」頁面中確認已選取「VMware ESX」選項，並在「Version」下拉選單中挑選【VMware ESXi 7 and later】。值得注意的是，如果使用的VMware Workstation Pro版本較舊，則在此選擇較舊版本的ESXi選項，然後按下〔Next〕按鈕。
在「Name the Virtual Machine」頁面中，輸入新虛擬機器名稱與設定檔案存放路徑，並按下〔Next〕按鈕。來到「Specify Disk Capacity」頁面，建議選取「Store virtual disk as a single file」設定，再按下〔Next〕按鈕。然後，在「Ready to Create Virtual Machine」頁面中，確認上述步驟無誤後按下〔Finish〕按鈕。
緊接著開啟「Virtual Machine Setting」→「Hardware」頁面，在「CD/DVD(IDE)」欄位中完成ESXi 7.x安裝映像檔案的載入設定。最後，在「Options」子頁面的「Advanced」選項中，如圖4所示，確認已將「Firmware type」區域內的選項設定成「UEFI」後，再按下〔OK〕按鈕。
圖4 虛擬機器選項設定。
完成新增與設定虛擬機器後，把準備好的USB磁碟安插在電腦上。接下來，就可以開啟此虛擬機器的電源，在啟動過程中，如圖5所示點選「VM」選單中的【Removable Devices】選項，並選取此USB磁碟的「Connect」功能以完成虛擬機器的連接。
圖5 使用虛擬機器功能選單。
進入ESXi 7.x系統的安裝頁面後，如圖6所示便可以在「Select a Disk to Install or Upgrade」頁面中，查看到此虛擬機器所連接的USB磁碟。按下〔Enter〕按鈕後，就能夠準備進行安裝任務。
圖6 選取安裝磁碟。
緊接著，整個安裝過程只要完成root密碼的設定與鍵盤配置的選擇即可。如圖7所示，便是成功完成安裝的「Installation Complete」顯示頁面。將安裝映像的連接設定取消，便可以在此按下〔Enter〕重新啟動ESXi系統。最後，只要進入到此電腦的BIOS配置中，將USB此磁碟設定為最高優先順序的開機磁碟來完成啟動即可。
圖7 成功完成安裝。
請注意！若ESXi系統在安裝過程中發現了不相容的裝置，或是沒有偵測到必要的裝置（例如網卡），則可能會無法順利安裝或是安裝後無法正常啟動。
備份與還原ESXi主機配置
任何虛擬化平台完成部署的初期，最重要的一項任務就是建立虛擬機器的備份計畫，以預防萬一發生主機硬體故障時，還能夠將虛擬機器的備份還原至其他主機中繼續運行。
上述的情境所指的是在獨立的ESXi主機運行中，若是運行在vSphere HA的叢集架構中則又另當別論。然而，除了虛擬機器的備份相當重要外，其實有關主機配置的備份也是一樣重要，因為管理者肯定不希望主機在完成部署後，所完成的一連串配置設定因為系統或硬體故障問題而導致所有配置必須從頭設定。為此，提供以下兩種備份與還原ESXi主機配置的方法。
首先是透過ESXCLI命令的備份方法。可以先透過SSH遠端連線至ESXi主機，在成功連線登入後，先執行「esxcfg-info -u」命令來取得UUID。
接著，再執行以下命令參數，便可以完成主機配置的備份，其中所產生的主機配置檔案的下載網址，只需要把「*」號修改成此主機的IP位址或FQDN於網頁瀏覽器的URL即可：
vim-cmd hostsvc/firmware/sync_config vim-cmd hostsvc/firmware/backup_config
有了ESXi主機配置檔案的備份後，若未來需要進行還原時該怎麼做呢？很簡單，只要參考以下的命令參數，並將其中的備份檔案存放路徑修改成實際存放的路徑即可。在完成主機配置的還原後，記得要將主機退出維護模式：
vim-cmd hostsvc/maintenance_mode_enter vim-cmd hostsvc/firmware/restore_config / backup_location/configBundle-ESXi03.tgz
接著，學習一下透過PowerCLI的備份方法。先確認已完成PowerCLI於Windows PowerShell中的安裝後，執行Connect-VIServer命令參數來完成ESXi主機的連線登入。一旦成功連線登入後，就可以如圖8所示執行以下命令參數來完成主機配置的備份。請注意！必須將其中的IP位址與目的地路徑修改成實際使用的設定：
圖8 PowerCLI備份主機配置。
Get-VMHostFirmware -VMHost 192.168.7.253 -BackupConfiguration -DestinationPath D:\Downloads
確認成功完成主機配置的備份後，未來就可以隨時執行以下的命令參數，將選定的主機設定進入維護模式，並將主機配置檔案備份至選定的路徑中：
Set-VMHost -VMHost 192.168.7.253 -State 'Maintenance' Set-VMHostFirmware -VMHost 192.168.7.253 -Restore -SourcePath D:\configBundle- 192.168.7.253.tgz -HostUser root -Host Password Passwd
同樣地，在完成主機配置的還原後，記得將主機退出維護模式。
如何修改ESXi主機名稱
如果ESXi主機的FQDN與現有網站連線的URL不同，可能會讓管理人員在維運過程中發生一些奇怪的問題，例如在部署OVF檔案時會發現〔上傳〕按鈕無法點選，或者在該主機的資料存放區內無法成功上傳檔案等等。
至於為何會發生ESXi主機的FQDN與連線URL不同的原因，有可能是在組織內網中已經部署Active Directory與DNS主機，而恰好vSphere的網域與Active Directory的網域名稱不一樣，此時如果ESXi的DNS位址設定指向Active Directory的DNS主機，便可能會發生ESXi自動將Active Directory的網域尾碼設定在FQDN的配置中。
想要解決這個問題，必須以命令的方式來變更ESXi主機的FQDN，而不能夠只是透過DCUI介面來修改DNS尾碼的設定。怎麼做呢？很簡單，如圖9所示，先執行「esxcli system hostname get」命令，查看現行ESXi主機的FQDN（Fully Qualified Domain Name）資訊。
圖9 查看目前主機與FQDN設定。
確認過要修改現行ESXi主機的FQDN設定後，執行以下命令來變更至新設定的FQDN，並再次檢查修改後的設定是否正確即可：
esxcli system hostname set --fqdn=ESXi03. lab02.com esxcli system hostname get
解決主機新增至叢集的警示問題
無論是對於ESXi主機的個別管理，還是透過vCenter Server的連線管理，在連線位址部分都建議輸入FQDN而不是IP位址，主要原因有兩點。第一是便於管理人員記憶及管理。第二則是若一開始使用IP連線方式，而後來又改成採用FQDN的連線方式，可能會出現許多類似接下來所要介紹的問題。
如圖10所示，這是一個在vSphere叢集中準備要新增ESXi主機時，所出現的警告訊息導致操作無法繼續。從警告訊息中可以看到所準備新增的ESXi主機皆已被另一台vCenter Server所管理，因此無法成功新增。
圖10 檢視主機摘要問題。
其實並非這一些ESXi主機已被其他vCenter Server所管理，而是先前已經先透過IP連線方式登入過這台vCenter Server，並將這些ESXi主機添加進來所致。
換句話說，針對上述這個問題，只要重新以IP連線登入vCenter Server的方式，來重新新增這些ESXi主機，便可以成功完成設定。
善用資源集區管理技巧
在小型的vSphere架構維運中，由於主機與虛擬機器的數量並不多，因此只要初始的資源充足，並不太需要煩惱CPU與RAM資源的自動化管理問題，因為即便需要添加資源，也僅須安排在離峰時間進行虛擬機器的移轉與主機的停機維護即可，整個維護過程並不複雜，
相對於中大型以上的vSphere架構，在平日的維運管理上可能就會複雜許多，其根本的原因除了在於虛擬機器數量相當多之外，虛擬機器內所運行的各類應用系統、資料庫服務也相當多，運行過程中隨時可能發生CPU與RAM資源的爭用問題，若資源配置不當，便會導致重要的系統效能受到衝擊，或是讓不需要太多資源的應用系統占用了過多的資源等問題。
為了妥善做好資源的管理，必須懂得善用vSphere資源集區的功能，來配置好每一個ESXi主機資源集區或是DRS叢集子資源集區的設定。首先，嘗試建立一個DRS叢集子資源集區，必須注意的是，當選定的叢集已關閉vSphere DRS功能時，在叢集的功能選單中，如圖11所示，會發現無法點選【新增資源集區】選項。
圖11 叢集功能選單。
這時候必須開啟「編輯叢集設定」頁面，然後如圖12所示在「自動化」頁面中先決定要採用的自動化層級設定，再設定vMotion移動臨界值，以及決定是否啟用Predictive DRS與虛擬機器自動化功能。接著，在「其他選項」頁面中，除了可以決定是否要啟用「虛擬機器分佈」與「CPU過度認可」功能外，還可選擇是否啟用「可擴充共用率」設定，以決定要不要為後續叢集資源集區的配置啟用可擴充共用率的功能。設定完畢，再按下〔確定〕按鈕。
圖12 啟用vSphere DRS設定。
完成了叢集DRS功能的配置與啟用後，接下來就可以正常開啟「新增資源集區」頁面，如圖13所示，首先完成新資源集區的名稱設定。如果想要在新增或移除虛擬機器時可以動態擴充共用率，則選取「擴充子代的共用率」設定。緊接著，便可以開始設定「CPU」與「記憶體」各自資源的分配方式。
圖13 新增叢集資源集區。
在「共用率」欄位中，有低、正常、高以及自訂四種可以選擇，前三種等級會分別以1:2:4的比率來指定共用率的值。舉例來說，假設現在建立一個名為RP-QC與一個名為RP-Sales，然後將RP-QC的共用率設定為「高」，而將RP-Sales的共用率設定為「低」，此時如果RP-QC的CPU共用率結果顯示為8000，而記憶體共用率顯示為327680，則RP-Sales的CPU共用率結果必定是顯示為2000，以及共用率顯示為81920。
在「保留區」欄位中，則是為該資源集區設定保證的CPU或記憶體配置量（預設值=0）。若在「保留區類型」欄位中將「可擴充」設定勾選，則對於該資源集區中運行的虛擬機器而言，如果總體保留區的資源大於該資源集區的保留區資源，那麼該資源集區將可使用父系或上層資源來繼續維持系統的正常運行。
在「限制」欄位中，可以設定此資源集區的CPU或記憶體配置量的上限值，在此系統也會提示它們各自的最大上限值，若沒有打算加以限制，選擇「無限制」即可。設定完成後，按下〔確定〕按鈕。
如圖14所示，目前於DRS的叢集之下已建立兩個資源集區，可以從它們的「摘要」頁面中檢視到相關的資源設定。接下來，可根據不同虛擬機器的資源需求，將它們移動到相對的資源集區中來運行即可，當然也能隨時將它們移出資源集區。
圖14 檢視資源集區摘要。
在vSphere叢集下建立資源集區的好處，在於能夠結合DRS的自動分配功能，來妥善維持虛擬機器的正常運行。不過，資源集區功能所帶來的好處，並非只能使用在叢集的虛擬機器管理中，也可以在叢集以外的ESXi主機進行建立。先在ESXi主機的「動作」選單中點選【新增資源集區】，接著在「新增資源集區」頁面中，如圖15所示，將會發現相較於DRS叢集資源集區，只少了「擴充子代的共用率」選項，其餘包含共用率、保留、保留區類型以及限制功能設定皆是有的，最後按下〔確定〕按鈕。請注意！如果已將某台ESXi主機新增到叢集，將無法建立該主機的資源集區。
圖15 新增主機資源集區。
使用PowerCLI管理資源集區
對於已熟悉PowerCLI命令介面的進階管理員來說，透過PowerCLI命令與參數的快速輸入方式來檢視與管理資源集區的配置，肯定比操作vSphere Client圖形介面更有效率。如圖16所示，在以下的命令參數範例中，便是先設定好vCenter Server的變數，再分別取得VM003與NAKIVO這兩個虛擬機器的資源配置狀態。從執行結果中可以清楚看到資源集區內，CPU與記憶體各自的共用率、保留以及限制設定：
圖16 查詢VM所屬的資源集區配置。
$Server = Connect-VIServer -Server vcsa01.lab02.com Get-ResourcePool -Server $server -VM VM003 Get-ResourcePool -Server $server -VM NAKIVO
接下來，執行以下命令參數來新增一個資源集區，如圖17所示，這裡將CPU的共用率自訂為3000，並將記憶體的限制設定為3GB：
圖17 修改資源集區配置。
Set-ResourcePool -Resourcepool RP-Marketing -NumCpuShares 3000 -MemLimitGB 3
在完成建立多個資源集區後，日後假設在ESXi01主機上有建立一個名為ResourcePool01的資源集區，如今想把它移動到ESXi02來使用，只要執行以下的命令參數即可完成資源集區的移動（同樣的需求，在vSphere Client操作介面中，則只要透過按住滑鼠左鍵的拖曳方式來完成即可）：
Move-ResourcePool -ResourcePool ResourcePool01 -Destination ESXi02
除了資源集區可以隨意進行移動外，若需要將某一個虛擬機器移動到選定的資源集區，如圖18所示，可以執行以下的命令參數，將NAKIVO虛擬機器移動到RP-Marketing資源集區內：
圖18 移動虛擬機器至資源集區。
Get-ResourcePool RP-Marketing Move-VM -VM 'NAKIVO' -Destination 'RP- Marketing'
對於一些規模較大的IT環境，單一層的資源集區恐怕難以管理大量的虛擬機器資源配置問題。為此，可透過父子階層的資源集區架構，來完成更精細的資源配置設定。
接著，就來嘗試在現行的資源集區之下新增一個資源集區，來做為子資源集區。先執行「$RP = Get-ResourcePool -Location Cluster -Name RP-Sales」命令參數，設定好父資源集區的名稱與位置。緊接著，透過以下的命令參數來新增一個名為RP-Marketing的資源集區至RP-Sales的資源集區之下，成為一個共用此父資源集區的子資源集區，並配置好各資源允許保留區的可擴充性，以及CPU與記憶體的資源保留、共用率等相關設定：
New-ResourcePool -Location $RP -Name RP- Marketing -CpuExpandableReservation $true -CpuReservationMhz 600 -CpuSharesLevel high -MemExpandableReservation $true -MemReservationGB 2 -MemSharesLevel high
子資源集區完成建立後，回到vSphere Client網站查看一下。如圖19所示，就會發現剛剛所建立的RP-Marketing資源集區，確實已新增至RP-Sales的父資源集區之下，成為了共用RP-Sales可用資源的一個子資源集區。此外，對於資源集區相關的數據統計，可查看此頁面中的統計圖，來得知目前集區中的虛擬機器和範本數量、已開啟電源的虛擬機器數量、子資源集區數量，以及子vApp數量。
圖19 查看子資源集區RP-Marketing配置。
主機管理人員權限配置
之前曾經完整介紹過關於在整合vCenter Server架構下的帳號、角色以及權限的管理，然而在一些情境下可能需要對於獨立的ESXi主機進行這方面的操作管理，例如混合部署的vSphere環境中，或是在無vCenter Server的多台ESXi架構下。無論如何，做好管理人員的權限配置，才是一個虛擬化平台安全運行的基本措施。
對選定的ESXi主機開啟並登入VMware Host Client網站，接著點選至「管理」節點中的「安全性和使用者」頁面。如圖20所示，在「使用者」子頁面中，會發現除了系統預設內建的root帳號外，還有另外兩個帳號JoviKu與Sandy，便是剛剛所新增。在新增過程中，僅需要設定使用者名稱與密碼即可。
圖20 使用者管理。
緊接著，點選至「角色」頁面中，如圖21所示，同樣可以查看到除了系統預設的系統管理員、匿名、無存取權、無密碼編譯管理員、無受信任基礎結構管理員、唯讀、受信任基礎結構管理員、檢視角色外，還有一個剛剛新增的「Admins」角色。在新增過程中，僅需要設定角色名稱以及授予的權限。
圖21 角色管理。
完成使用者與角色的新增設定後，接下來說明如何授予主機相關物件的權限。直接在「主機」節點的頁面中，透過點選「動作」選單中的【權限】進行權限配置。當然，也可以選擇在「儲存區」或是選定的虛擬機器頁面中進行權限的配置設定。
開啟「管理權限」頁面後，點選「新增使用者」。接著，便可以針對所選定的使用者，如圖22所示賦予任一角色權限。除此之外，還可勾選「散佈到所有子系」，讓所賦予的權限往下繼承。設定完成後，按下〔關閉〕按鈕。
圖22 管理權限。
對於使用者沒有權限管理的物件或配置，使用者便會發現相對的功能選項無法點選，或者在執行後出現了權限不足的錯誤訊息。如圖23所示，便是當使用者沒有被賦予虛擬機器的管理權限之時，一旦執行了新增虛擬機器的操作，便會出現「虛擬機器組態遭拒絕，請查看瀏覽器主控台」的錯誤訊息。
圖23 無法新增虛擬機器。
主機鎖定模式之應用
在vSphere的虛擬化平台架構中，提供了許多與資訊安全有關的功能配置，包括防火牆配置、權限管理、身分驗證機制、Authentication Proxy、密碼管理、虛擬機器加密、UEFI安全開機、網路傳輸加密等等，可以說能夠完全根據實際IT環境的需要，建構出滿足任何組織資訊安全的規範。
除了上述的各類安全功能外，還有一項容易被管理員忽略的主機安全性功能，那就是鎖定模式（Lockdown Mode），此功能有助於提升在以vCenter Server集中管理的架構中，對於每一部ESXi主機連線的安全管制，讓管理人員無法經由SSH、ESXi Shell或第三方軟體（結合vSphere API）等方式進行連線登入，真正做到完全由vCenter Server集中管理的嚴格要求，以及可達到僅有選定的單一vCenter Server才能夠完全管理這一些ESXi主機的目標。
關於鎖定模式的功能，可透過DCUI介面的使用，在按下〔F2〕鍵並完成登入後，如圖24所示發現「Configure Lockdown Mode」選項就出現在「System Customization」頁面中但卻無法選取，是什麼原因造成的呢？
圖24 系統配置選單。
主要原因是必須先透過VMware Host Client，開啟「管理」→「安全性使用者」頁面，如圖25所示便可以從「鎖定模式」頁面中來啟用此項功能，並且還可以進一步新增例外的使用者名單。
圖25 鎖定模式管理。
在點選「編輯設定」操作時，將會開啟「變更鎖定模式」頁面。在預設狀態下便是處於「已停用」，可以選擇「嚴格鎖定」或「一般鎖定」來啟用此項功能，前者會限制管理人員只能從vCenter Server來連線登入與管理，後者則允許管理人員經由DCUI或vCenter Server連線登入與管理。決定好了之後，按下〔變更〕按鈕。
啟用鎖定模式功能之後，若沒有特別新增使用者例外的名單，則所有管理人員都必須透過登入vSphere Client網站或DCUI的方式，才能夠管理ESXi主機的各項配置，否則在嘗試以其他方式連線（例如VMware Host Client）登入時，將出現如圖26所示的「執行此作業的權限遭到拒絕」錯誤訊息。
圖26 使用者無法登入VMware Host Client。
以SSH遠端開啟DCUI管理介面
對vSphere 7.0管理人員而言，最重要的三大管理工具分別是遠端管理使用的vSphere Client網站、SSH Client以及近端管理的DCUI（Direct Console User Interface）介面。在平日維運的過程中，絕大部分的情況下只會使用到vSphere Client網站來處理各種管理上的運行需求，其次則可能透過SSH Client的連線，查詢或修改一些更細部的系統配置。
至於DCUI，通常非到不得已是不會使用的，例如因為某修改故障因素導致vSphere Client與SSH皆無法進行遠端連線時，導致管理人員必須到主機端執行像是root密碼的更新、主機重新啟動等等操作。
不過，也有許多管理人員平日就已喜好透過DCUI來進行基本網路配置的設定、網路的測試、Shell命令工具的使用等操作。建議這類的管理員除了可設定延長DCUI的閒置逾時時間外，還可以進一步透過SSH的遠端連線方式來直接操作純文字介面版本的DCUI工具。
方法很簡單，首先在DCUI的首頁中按下〔F2〕鍵並完成root帳密的驗證，接著開啟「Troubleshooting Mode Option」頁面，先完成啟用SSH服務，再選擇開啟「Modify DCUI idle timeout」，如圖27所示。
圖27 故障排除模式選項。
如圖28所示，在「Set idle time for DCUI access」頁面中，輸入以分鐘為單位的閒置逾時時間，最大值是1,440分鐘。如果想要關閉閒置逾時功能，只要輸入0即可。輸入完畢，按下〔Enter〕按鈕完成設定。接下來，可以透過任一的SSH Client連線登入ESXi主機。成功登入後，先執行「vmware -v」命令，查看目前的VMware ESXi系統版本是否為7.0以上的版本，確認沒有問題後，再執行「dcui」命令。
圖28 設定DCUI逾時時間。
如圖29所示，便是透過SSH Client連線登入後，所開啟的純文字介面版本的DCUI介面，其操作方式與主機端的DCUI皆是一樣的，換句話說，有了這項工具，在往後維運過程中，除非網路無法連線，否則對於有DCUI操作需求的管理人員而言，通通只要經由SSH Client的遠端連線後即可開啟。
圖29 SSH開啟DCUI操作介面。
結語
無論組織IT的規模有多大、架構有多麼複雜，想要有高效率地管理VMware vSphere虛擬化平台，除了要懂得善用內建的管理工具外，還可藉由整合自家或第三方的解決方案來全面提升效率，例如曾經介紹過的VMware vRealize Operations，或是ManageEngine OpManager等等。不過，這些工具只能協助監視及發現運行上既有問題或潛在問題。
其實，許多時候，IT人員需要的是使用經驗的分享，然而這些經驗若只能夠從筆者的文章、其他專家文章、討論區或是VMware Knowledge Base來獲得，似乎仍不夠快速與方便。試想若能夠進一步結合AI機器人的技術，讓AI直接根據這些專家資料來源精準回應問題，而不是像現階段得透過Google搜尋引擎方式，大海撈針地找尋相對應的解答，許多時候可能還有開啟惡意網站的風險。因此，期待官方在善用AI技術來解決系統運作問題的同時，也能夠思考藉由AI來解決專家經驗支援的需求。
＜本文作者：顧武雄， Microsoft MVP 2004-2016、MCITP與MCTS認證專家、台灣微軟Technet、TechDays、Webcast、MVA特約資深顧問講師、VMware vExpert 2016-217、IBM Unified Communications/Notes/Domino/Connections Certified。＞