【vSphere故障案例】
在這裏，我們記錄一些在ESXi主機上發生的、相當常見的問題。通常，可以採取一些簡單的步驟去解決這些問題，但有的問題就需要較深入的解決方法。
藍屏死機（BSOD遇到的很少）
粉屏死機（PSOD，Pink Screen of Death） PS：其實和紫屏死機一樣
紫屏死機（PSOD， Purple Screen of Death）
有一種在ESX和ESXi主機上都可能發生的故障，叫做紫屏死機（可以說是臭名昭著的微軟藍屏死機的VMware版）。紫屏死機會導致ESX/或ESXi主機突然崩潰、變得無法操作。你一定不希望在自己的主機上發生這種現象。以下是我遇到的一些紫屏死機故障現象和我收集的一些紫屏案例。
當PSOD發生時，ESXi會完全死機，沒有任何反應。硬件問題（壞有問題的內存是最常見的原因）或ESXi中的BUG是導致PSoDs的典型原因。當PSoDs發生時，你只能關閉並重啓主機。屏幕上的提示信息非常有用，應該嘗試記錄它：可以使用帶有拍照功能的手機給它照相，或者，如果存在的話，可以從一個遠程管理面板上截圖。你或許看不明白這些捕獲下來的信息，但是，這些信息對VMware的技術支持來說非常有用。屏幕上顯示的信息包括ESX的版本和build號、異常類型、寄存器轉儲（register dump）、崩潰時每個CPU正在跑什麼、回溯追蹤（back-trace）、服務器運行時間、錯誤日誌、內存硬件信息等。
當你遇到PSoDs並重啓主機之後，在ESX主機或/root文件夾下，會有一個以vmkernel-zdump開頭（命名）的文件，在ESXi5.0之後該文件位置放在”/scratch/core/vmkernel-zdump.1”。這個文件對VMware技術支持非常有用，同時，你也可以使用該文件，通過vmkdump工具提取 VMkernel日誌信息、尋找與PSoDs有關的線索，從而判斷PSoDs發生的原因。要使用這個命令，輸入vmkdump –l dump <文件名>，ESX4（或ESXi5.0）之後是沒有這個命令的，替代的命令是esxcfg-dumppart，用法：esxcfg-dumppart -L <ESX dump file>。
例如：
~ # ls -l /scratch/core/
-rwx------ 1 root root 104858112 Dec 5 01:46 vmkernel-zdump.1
~ # esxcfg-dumppart -L /scratch/core/vmkernel-zdump.1
Created file vmkernel-log.1
~ # more vmkernel-log.1
參考：
http://www.vmsky.com/tech/vmware/vi3/2009/08/27/5673.html
http://kb.vmware.com/kb/1002769
如前所述，壞有問題的內存是PSoDs中常見的原因。 你可以使用dump 文件識別引起問題的內存模塊，從而將其替換掉。
紫屏案例收集
VMware官方社區關於紫屏的文章
http://blogs.vmware.com/kb/2012/07/purple-diagnostics-screen-articles.html?src=WWW_BestMatch_CN
案例一：紫屏死機PSOD
IBM雙刀VMware ESX4.0紫屏死機，如圖：
發生時間：2011-11-13 （星期天）
硬件：IBM刀片服務器雙刀4*8431\8*8GB\Flash or HHD*2\HBA
軟件：ESX 4.0
故障現象：紫屏死機
故障原因：不可識別的CPU或有缺陷的CPU（或CPU損壞）
解決建議：更換CPU
處理故障過程（方法）：一般紫屏，絕大部分情況都和硬件有關係，查看報錯信息的關鍵部分“#PF Exception(14) in world 0:unknown ……”。
PF：虛擬內存，CPU使用率與PF使用率就相當於你電腦的CPU配置及內存條大小與系統性能的正比關係。
我這個ESX主機是IBM的雙刀服務器，有多個CPU和兩塊主板，查找了相關紫屏資料和詢問相關專家，初步懷疑是CPU導致紫屏的。當時是傍晚發生的故障，而且又是公司主要的郵件服務器，又沒有備用的，第二天週一還得正常時候，報修是來不及了的，時間很緊。重啓主機後還是紫屏狀態，請教專人後，我們把雙刀的第一塊主板上的第一個CPU1取了下來，然後重啓，主機正常起來了。（PS：好像後來說是CPU1的插槽有問題，報修了）。