三節(jié)點主機組成的vSAN環(huán)境，每個ESXi6.5版本為4887370環(huán)境，HA集群運行狀態(tài)良好，采用vCenter自帶的Update進行補丁更新。由于啟用了DRS，每補丁一個節(jié)點時都會自動漂移虛機，平時更新也都未做特別處理，點完鼠標就不管了。而這一次，更新到最后一個節(jié)點主機，居然沒有更新成功。于是，關閉DRS，手工漂移更新未成功的主機節(jié)點上所有虛機，此時，發(fā)現(xiàn)其中一個主機的“遷移…”選項是灰色狀態(tài)無法操作。

首先檢查該虛機仍處于開啟和正常運行狀態(tài)，虛機所承載的服務也正常。接著，查看虛機摘要，確定虛機關聯(lián)的主機IP，發(fā)現(xiàn)虛機并未關聯(lián)在補丁更新失敗的主機上，卻又在補丁更新失敗的主機的虛擬機清單中能看到，這也難怪“遷移…”菜單不可操作。根據(jù)以往經(jīng)驗，這是虛機遷移過程非正常結束導致的狀態(tài)錯亂。此時，虛機在開機的狀態(tài)也無法清除，因此考慮關機后從清單中移除，然后重新添加到清單就能解決。

為避免意外，專門點開vSan瀏覽文件目錄，虛機同名的文件夾里竟然是空的，過去也只遇到過vSAN性能遲緩，多次刷新才能緩慢刷出文件列表的情況，難道這與無法遷移有關系？想著反正虛機都在運行中，文件肯定在存儲上，也就不管其他的了，將虛機正常關閉，然后從清單中移除了。

再次進入vSAN瀏覽文件目錄，找到同名文件夾，點開后等了很久久，就是顯示文件夾中沒有文件，刷新了十多次后依然如此，不由得開始背脊發(fā)涼，該不會又給自己挖坑了吧。

立即查看操作日志，反復確認剛才點擊的是清單中移除，而非刪除，可虛機文件去哪了……莫非是vSAN節(jié)點的補丁版本不同，有什么Bug，被這個虛機碰巧觸發(fā)了，造成了虛機文件的不可見？想起還有VDP這最后的稻草，可打開后發(fā)現(xiàn)，VDP就沒有將該虛機添加到備份計劃中，雖然直覺堅信虛機一定還在存儲上，可怎樣能“挖”出來呢？

無奈只有求助客服了。費了好多口舌，不斷地提交收集的各種日志，歷經(jīng)了一周的心理煎熬，終于將Case升級到三線工程師來遠程處理，僅一條命令的檢查瞬間讓我看到了希望的曙光。

從上述命令的結果中，迫切地看到了object path已經(jīng)顯示了丟失虛機的vmdk路徑，緊接著，工程師利用上述查到的group uuid查到了虛機的用戶命名user friendly name。

從user friendly name可以看到，虛機的命名多出來了一個下劃線和數(shù)字1，并且這個用戶命名在WebClient的文件瀏覽中也看不到。虛機文件僅存于uuid命名的文件夾中，這也是從清單中移除后沒能在vSAN文件瀏覽里找到虛機的原因了。

事已至此，抓緊時間在WebClient的文件瀏覽中，找到9fbf開頭的uuid文件夾，右鍵vmx文件添加到清單中，結束該虛機業(yè)務長達一周的中斷。虛機開啟后，檢查服務狀態(tài)均正常，同時也自動生成了用戶命名的文件夾。最后，為避免產(chǎn)生歧義，刪除不含“_1”的同名空目錄。

小結：分布式文件系統(tǒng)的技術已經(jīng)出現(xiàn)了很多年，雖然還在不斷發(fā)展進步中，但基本的可靠性還是具備的。除非是確實操作了從磁盤上刪除虛機，否則并不會輕易就丟失了。

三線工程師敲的第一條命令包含了一個uuid，該uuid是虛機所擁有的眾多vmdk中的一個虛擬磁盤的，猜想可能來自于我所提供的日志信息中，objtool命令是查看vSAN文件對象的高級命令工具，通過該工具進一步獲取了虛機對象的詳細信息，這才獲悉了虛機文件真正對應的uuid是9fbf開頭的目錄，而非b4ae開頭的空目錄。

反思整個問題的成因，可能是該虛機曾經(jīng)從這一集群storage vmotion移出去過，因為某些原因在移出后并未自動刪除文件目錄，僅保留了一個空目錄，而后該虛機又遷移回該集群，于是，同名文件夾不能被創(chuàng)建，vSAN僅創(chuàng)建了uuid命名的目錄，并一直以uuid目錄運行，沒有創(chuàng)建用戶命名目錄，也就出現(xiàn)本案從清單中移除后找不到虛機文件的“險情”。相對于已存在的同名文件夾，遷回的虛機并不會去覆蓋，這也是一種有效的保護機制，避免先存在于磁盤的文件被覆蓋。