虛擬化是個好東西。但是如果物理主機出現宕機，其影響會是致命的——這甚至可能會讓人渴望回到“每項功能一個物理服務器”的時代，仔細分析一下怎樣做會對公司和用戶有用，並決定用何種最佳的方式解決可能會出現的突發問題吧。
任何虛擬化戰略的第一步，都應該包括如何處理預想中的災難恢復。很多東西並不那麼適合於虛擬化環境:
任何已經混亂無序或過於陳舊的東西
很多人將物理設備轉變爲虛擬機，隨之它就可以被複制或存儲了。在某些情況下，這種做法是有用的，但是在其他特殊情況下，這種做法實際上只是讓一些雜 亂無序的舊操作系統維持了更長的使用時間而已，它們早已超過了應有的使用期限。例如，一個已經使用了幾年的Windows XP電腦被轉換成了虛擬鏡像。照這種情況來說，該系統已經歷了無數次的軟件升級、刪除內容等操作。又有幾年過去後（以及伴隨着更多的系統變更），無疑的 是，現在這個XP系統將表現出嚴重的CPU過載及反應時間過慢等問題。其實，更好的決策是從頭創造一個全新的映像，並以有序方式安裝必要軟件，而不是讓這 個千瘡百孔的操作系統轉爲一個虛擬系統重新上線。
任何必須要保證安全的內容
這條與第5條有些許不同。如果對任何含有管理者不想讓其他員工接觸到的安全信息的系統進行虛擬化，也許就會構成一定安全風險。管理者可以在虛擬機器 上設置訪問許可，防止其他人能夠進行控制，但是如果那些員工有能力控制主機系統，那麼這種控制手段也許就被規避了。他們也許依然能夠在任何地方複製 VMware文件，進行關閉服務器等操作。
任何沒有經過測試的關鍵任務
如果沒有在虛擬平臺上做過測試的話，就不要急於遷向虛擬化。即使需要花費時間，也要先測試了再說。對源進行拷貝，然後制定測試計劃，確保所有程序或 者服務器如預期的運轉。如果需要的話，在下班時間進行這一切。畢竟，在晚上11點發現問題總比在早上9點強。將原始源代碼保持離線（僅僅是關掉，但不要斷 開/刪除/卸載），直到確保如預期那樣朝着新目標進發。