沒想到重開之後悲劇就發生了，SR有錯誤，後來才知道是因為漏關了一個VM，想說應該不難處理吧，最多VM不正常關機做一下磁碟檢查就可以修復了。
因為自覺問題不大，於是想了一個走捷徑的方法——直接到 XENSERVER手動卸載再重新掛載NFS分享，再到SR重新掃瞄，果然恢復——沒有錯誤了。
再靠近一點看，什麼，VDI全部消失了，再重新掃瞄——當然還是沒有，檢查一下是不是掛載點有問題——果然手動掛載後多了一層SR的UUID，應該可以改回來吧！
還是不要亂玩好了，用XENCENTER裡的DETACH再REATACH應該就會回來吧，果然VDI沒有棄我而去，全部再次出現。
可是、可是，全部的VDI都只有大小，沒有NAME-LABEL、也不知道所屬的VM是誰，一共20幾個VM，每個VM2個VDI，再乘上4倍的SNAPSHOT，天啊！100多個VDI要怎麼幫它們配對。
呆了半個小時已經晚上11:00了，打起精神做好熬通霄的心裡準備，先GOOGLE看看吧！當然有人遇過，但是只找到一個解法，他因為平常有做META DATA的備分，就把XML格式的META DATA打開，一筆一筆找UID，一個一個對應回去，可是我只有剛上線的時候有做META DATA備分，那時候VM又沒幾個，遇到這種情況根本不用擔心。
凌晨12:00終於下定決心，一個一個VDI打開來看是屬於那個VM，再一個一個掛回去。
1.在XENSERVER裡SR的目錄中，使用 ls -lth依時間排序VDI，從最新的開始做，全部VM做完剩下的VDI就是SNAPSHOT，可以暫時不管它。
2.複製最新VDI檔的主名檔，這也是VDI的UUID，使用xe vdi-param-set name-label=tmp_disk uuid=剛剛複製的主檔名，這時VDI就有了臨時的名稱。
3.在XENCENTER中用唯讀方式隨便掛上一台已經開機的VM。
4.用盡全力尋找蛛絲馬跡，判斷這個VDI屬於那個VM。
5.在XENCENTER中修改為正確的名稱。
6.VDI從臨時VM卸下，掛到正確的VM。
弄了一個晚上總算趕在凌晨5:00多天亮前都掛上去，逃過上班被罵的命運。
<<<<<< 一段小插曲 >>>>>>>
WIN SERVER 2008以後的開機碟一定要用唯讀掛載，不然開機區會被改掉，掛到正確的VM也不能開機，修正方式為，使用安裝光碟開機，進入主控台修復模式，CD C:\WINDOWS\STSTEM32 執行，以下三個指令，就可以修復。
bcdedit /set {default} osdevice boot
bcdedit /
bcdedit /set {default} detecthal 1
>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<< 判斷VDI是那個VM的，真的非常困難 >>>>>>>>>>
判斷VDI是那個VM的真的非常困難，而且大多數的VM都是開給別人用的，不是自己在用，我又是系統碟、資料碟分開建的分式，系統碟還好，大不了進REGISTERY查電腦名稱，一定查的出來；資料碟通常更難判斷。後來用的最多也最也最快的方式是——從磁區大小和剩餘空間來判斷，可是又怎麼可能記得每個VM磁區的大小和剩餘空間呢？這要得力於我之前因為覺得VM數量實在愈來愈多，就導入了OCS INVENTORY——開源的資產管理軟體，來管理，這次真的幫了大忙。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<< 避免再次發生 >>>>>>>>>>>>>>>>>>>>>
什麼這種慘劇一次還不夠，還會再發生，建議在XENSERVER執行 xe vbd-list param=all is-a-snapshot=false > vdi-list.txt ，再COPY到自己電腦存檔有備無患。其實XENSERVER使用UUID來描述物件，強迫使用者用系統指令或介面操作物件，避免使用者直接對檔案進行操作，應該是比較先進，可以減少人為錯誤的操作方式，但是一旦手殘亂弄，弄出問題卻也讓除錯變得比較困難，那種方式比較好？只能說各有優缺點吧！畢竟使用者的選擇其實不多，用久了就知道地雷在那裡，就可以盡量發揮優點避開缺點。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
