當VMware管理員談論工作中所犯的錯誤時，我經常說，如果你沒在犯錯，那麼你就沒在學習。
一些錯誤是由於嘗試導致，其他一些是由於缺乏知識。而還有一些是我們應該已經知道不該去做的蠢事。但是最後，因為曾經犯的錯誤，我們成為了更好的VMware管理員。
以下是特約專家Mike Nelson曾經看到、聽到和經歷過的令人難忘的VMware管理員所犯的錯誤。
VMware管理員錯誤1:虛擬機重命名
這種錯誤非常典型。在vCenter中對虛擬機重命名非常簡單：右鍵單擊客戶機，選擇“重命名”,然後輸入新的名字。
但是這個操作僅僅是重命名vCenter數據庫中的對象指針，和虛擬機關聯的目錄和文件仍然在原來的名字下。對於VMware管理員來說，快速清理數據存儲過程，刪除虛擬機目錄和文件，只需要點一下鼠標，非常容易，尤其是在沒有客戶機和當前目錄相匹配的情況下。我已經看到過這種事情發生，而且後果很嚴重。
VMware管理員錯誤2:塞滿整個LUN
我多年前參加一個會議，是和VMware ESX 3新特性有關的活動。演示人員在SAN上創建了一個100GB的LUN,並把它分配給一個用於演示的包含兩個節點的集群。
他在這個LUN上創建了三個虛擬機，每個虛擬機有32GB的硬盤以及2GB ISO共享數據存儲。計算一下，使用的存儲空間為：（32GBx3）+ 2GB = 98GB.對於一個100GB的LUN來說，還有足夠的空間，是這樣嗎？
他一個個地啟動了所有的虛擬機。當啟動第三個虛擬機時，所有的虛擬機都死機了。看來是他忘記了啟動虛擬機時會創建交換文件。這些交換文件填滿了整個LUN,更有趣的是因為他不知道為什麼會發生這種情況，所以他再次嘗試啟動虛擬機。
是的，他是一個VMware工程師。
VMware管理員錯誤3:網絡名稱
我曾經是Citrix公司一個小機構項目的顧問，這個機構的存儲工程師在管理新的虛擬化環境。一天，我接到了他的一個電話。在進行vMotion操作時，他遇到了問題，並且分布式資源調度（DRS）也產生了許多錯誤。（我提到這家伙是個存儲工程師了嗎？
我登錄到vCenter上，發現所有的ESX主機並沒有設置在相同的網絡上。每個虛擬交換機在每個主機上具有不同的名字，當ESX主機沒有被同時創建或者沒有遵循命名規則（或者甚至不存在命名規則）時，這是一個很常見的錯誤。VMotion要求DRS集群中所有主機的虛擬交換機名稱是相同的。
VMware管理員錯誤4:蜜月和角色
有個VMware管理員在去度蜜月前不得不修復一個虛擬化問題。在他離開前，他確定在vCenter中從角色中移除人員，鎖定基礎設施。
但是他移除了vCenter對象--不僅僅是虛擬機或集群，具有訪問權限的角色。這個操作阻止任何人有權限去訪問vCenter對象。
我從他的新娘那聽到了這個故事，因為錯誤操作導致蜜月擱淺，她壓根兒就不高興。
VMware管理員錯誤5:網卡全軍覆沒
了解的VMware主機配置文件在一年後才出現，我有些等不及了，迫不急待地在超過500個主機的基礎實施中快速部署標准的主機。但是當我最終使用主機配置文件時，一下子全錯了。
我創建了一個新的主機配置文件並在實驗室主機上進行測試。在主機上測試一些虛擬機後，看起來並沒有任何問題。因此我決定在生產環境中包含16個主機的集群上應用主機配置文件。
稍後，vCenter看起來一切正常。我剛剛高興了5秒鐘，就產生了告警。我所有的虛擬機和主機都不能通過網絡進行訪問。
ESX主機配置文件的一個問題就是不管網卡速率在配置文件中設置為多少，所有讀取配置文件的主機速率默認都設置為自適應模式（當然，VMware稱之為它的一個特性）。
這個設置在網絡中交換機端口被硬編碼為1000M或者無故障恢復的Full模式時，不能運行（實驗室網絡端口是auto模式，所以能夠正常運行）。一旦將這個設置應用到所有的主機上，整個集群被拖垮了。我不得不在重新每個主機上手動配置14塊網卡，這整整花費了一天時間。
神馬？VMware自己也犯錯？
記得ESX 3.5 Update 2嗎？世界各地上千台主機在慘敗之後宕機了。
VMware不會輕易承認用戶群發現的bug是存在的。如果你安裝了ESX 3.5 Update 2，一旦時鐘改到2008年8月12日上午12:01，你不能進行vMotion或者啟動任何的虛擬機。
VMware最終承認問題是由於一段代碼導致了許可證過期，並且這段代碼以某種方式通過了測試版的測試和質量控制而引起的。 這個“計時炸彈”bug造成了嚴重的問題，唯一的解決辦法就是禁用服務器上的網絡時間協議（NTP），並且設置時鐘可追溯至2008年8月10日。 VMware在8月14日發布了一個補丁，但眾多的客戶將會對VMware的產品和它所做的測試持謹慎態度。
VMware首席執行官Paul Maritz先生給客戶發送電子郵件，就bug進行了道歉，表示這種問題將永遠不再發生。
