ESXi 主機失聯、datastore 爆滿快照合併失敗、授權過期，都會讓虛擬化平台停擺。從 hostd／vpxa、APD／PDL 到快照 1.5 倍合併餘裕，按官方順序拆根因，少踩重啟服務的雷。高雄廷皓科技。
主機 not responding：先確認 VM 還活著，再談排查
為什麼 APD 時「一鍵重啟服務」會害你
APD 最典型的成因，是有人在陣列端把 LUN 直接取消對應（unpresent），卻沒先在主機把 datastore 卸載乾淨。ESXi 還以為裝置在，於是對它送出的每一個 SCSI 指令都無止盡地重試；而 hostd 要巡查儲存狀態時，指令也一起卡在這條回不來的佇列上，整支代理程式就被拖到沒反應。這裡有個一定要記住的雷：別一上來就在主機 shell 下 services.sh restart 把所有服務一次全重啟。在 APD 情況下，這道指令本身會因為儲存卡住而掛在那裡跑不完，不但救不了主機，還可能讓局面更亂。正確做法是只單獨重啟需要的那一支——先 hostd，不行再 vpxa，真的沒轍才考慮整批。而且要清楚：重啟管理服務會中斷當下正在跑的管理工作，不是零成本的動作。
APD 跟 PDL 要分清楚，因為處置完全不同。PDL 是陣列主動透過 SCSI sense code 告訴主機「這顆 LUN 我確定回不來了」，屬於永久性，且只發生在區塊儲存；這時該做的是把受影響的 VM 收拾乾淨、把裝置正式移除。APD 則是「暫時全斷、生死未卜」，主機不知道還會不會回來，所以預設會苦等——這個等待時間預設是 140 秒，超過才正式宣告 APD timeout。先記住這個 140 秒，是後面談 HA 兜底的關鍵。
照順序排查：每做一步就驗一次，別跳步
官方那套排查流程之所以要求「一步一驗」，不是龜毛，而是每一步都在幫你縮小根因範圍，跳步只會讓你在錯的層次瞎忙。實務上的順序大致是：
- 先在 vCenter 對主機按重新連線（Reconnect）：很多短暫抖動按一下就回來了，根本不必動主機。
- 確認 vCenter 認的管理 IP 正確、且仍在收心跳：IP 對不上，後面全是白工。
- 從 vCenter 端 ping 主機 IP 與 FQDN，測 902／443：分辨問題是在網路層還是主機層。
- 網路確定沒問題，才進到重啟管理代理程式：而且是單獨重啟，不是一鍵全清。
- 連 SSH／DCUI 都進不去，才考慮最後手段：在確認 VM 已安全的前提下，才動到主機硬重開。
把順序反過來做——一失聯就先硬重開主機——是現場最常見、也最貴的錯誤。你等於在還沒搞清楚 VM 死活時，親手把一整批還在服務的 VM 強制斷電。
Datastore 爆滿，快照合併跟著卡死
另一個經典災難，是 datastore 空間被吃到見底，而元兇十之八九是沒收乾淨的快照。要防這種死法，得先搞懂快照在底層到底是什麼東西。
快照為什麼會失控長大
很多人以為快照是「把 VM 完整複製一份」，其實剛好相反。打下快照的瞬間，原本的母碟（base vmdk）被凍結成唯讀，系統另開一個差異檔（delta vmdk，也叫 redo log），之後所有新的寫入都改往這個差異檔記。它本質是一本「異動流水帳」，不是完整副本。麻煩就在這裡：差異檔會隨著 VM 持續寫入而不斷長大，以固定區塊（常見是 16MB）為單位往外擴，理論上限可以逼近整顆母碟的大小。一台 VM 忘了刪快照、掛著跑上好幾個月，差異檔把整個 datastore 吃乾抹淨，是我們現場見過太多次的死法。空間一滿，VM 輕則被暫停，重則跳出「需要合併磁碟（Consolidation needed）」卻又合不動。
更隱蔽的代價是效能。快照鏈越長，讀取越慢——因為讀一個近期沒改過的區塊，系統得從最上層的差異檔一路往下翻，直到母碟才找得到資料。一條深度 5 的快照鏈，最壞情況一次讀取要跑 6 次 I/O（五層 delta 各查一次，再加底層母碟一次）。對一台每秒好幾千 IOPS 的資料庫 VM，這個放大倍數會實實在在反映在延遲上。所以官方雖然允許一條鏈最多疊到 32 個快照，實務上強烈建議只留 2 到 3 個；而任何單一快照，都不該掛超過 72 小時。
合併也要空間：1.5 倍原則與 clone 解法
故障率、復原成功率與工時不適合用別人的平均值推估。現場應留下資產、告警、備份、還原演練、事件處理與停機紀錄，再用自家數據決定汰換、容量與維運優先順序。
這也帶出一條該列入 SOP 的原則：快照是「短期過渡」的工具——升級前、打補丁前留一個好回復的點，用完就刪。它不是備份，更不能長期掛著。刪完還一定要回頭確認真的合併完成（vSphere 會用「Consolidation needed」旗標提醒你，別忽略那面小旗子）。真正要長期留存資料，請走正規備份機制，那才是設計來保存、且能確實還原的東西。
讓 HA 幫你兜底：別把儲存故障全靠人肉盯
前面那個 140 秒不是白提的。vSphere 6.0 之後有一個叫 VM Component Protection（VMCP，VM 元件保護）的機制，專門處理 APD／PDL：當主機偵測到某個 datastore 進入 APD、熬過 140 秒仍未恢復，HA 可以依你設定的策略，再等一段延遲（預設約 3 分鐘）後，自動把受影響的 VM 搬到還能存取該儲存的其他主機上重開。PDL 因為是「確定回不來」，反應可以設得更果斷。再搭配 datastore heartbeat（讓 master 主機透過共用 datastore 判斷 slave 是真死還是只是網路孤立）與手動指定的 das.isolationaddress（隔離偵測位址），你就能讓平台在半夜沒人顧的時候，自己先把 VM 從壞掉的儲存路徑上救起來，而不是等到早上上班才發現一整排 VM 躺平。這是把「人肉救火」升級成「平台自癒」的關鍵設定，偏偏最常被跳過。
授權過期與升級：別讓平台在最忙的時候降級
還有一類不是壞、卻會把你手腳綁住的狀況：授權。ESXi 評估版或授權到期後，通常不會立刻把正在跑的 VM 停掉，但會開始鎖功能——不讓你開新 VM、不讓你用進階特性，然後跳出一整排過期警告。處置其實很單純：在到期前就把正式授權指派上去，並把各主機與 vCenter 的授權狀態、到期日列入定期巡檢，別等紅字冒出來才在生產時段手忙腳亂。
升級 vSphere 同樣要按部就班，最忌諱在沒退路時直接點 Update。動手前務必先查相容性矩陣：硬體、韌體、VMware Tools 版本、上層應用，任何一項對不上都可能升到一半卡住。順序也有硬規定——vCenter 一定要先於 ESXi 主機升級，反過來會踩到版本不相容；而且動手前務必留好可回復的備份或快照。虛擬化平台牽一髮動全身，寧可多花半小時把退路確認清楚，也不要在點下去之後才發現回不來。
常見誤區與該提前設好的防線
- 「主機失聯就是 VM 掛了」：大多數時候只是管理通道斷，先確認 VM 死活，再動任何手。
- 「快照就是備份」：快照是異動流水帳、死死依賴母碟，母碟壞了快照一起陪葬，長期留存請走正規備份。
- 「空間不夠就硬合併」：沒有 1.5 倍餘裕的合併只會失敗，甚至讓 VM 更難救，先騰空間或改用 clone。
- 「datastore 滿了再說」：應該在 vCenter 對每個 datastore 設用量告警（建議 75%、85% 兩段），並定期掃有沒有掛超過 72 小時的老快照。
廷皓科技服務高雄、台南、屏東的南台灣企業。ESXi 主機失聯的緊急判讀、datastore 與快照的空間治理、HA／VMCP 的兜底設定，一路到授權盤點與 vSphere 升級規劃，這些我們在不少在地工廠與公司都實際處理過。虛擬化平台一停，往往就是整片業務跟著停；與其在事故當下自己冒險敲指令，不如先讓廷皓遠端會診，把風險擋在事故發生之前。
