在檢測到錯誤時，將Linux服務(wù)器上的文件系統(tǒng)配置成重啟后的只讀模式是常見做法。不過，這種設(shè)置在結(jié)合使用VMware VI3時可能有意想不到的結(jié)果。
在發(fā)生錯誤時，Linux文件系統(tǒng)能配置成三種不同的模式：
errors=continue / errors=remount-ro / errors=panic
這三種模式分別表示忽略錯誤并只標記文件系統(tǒng)錯誤繼續(xù)運行，或者重啟系統(tǒng)為只讀，或者終止系統(tǒng)。
默認設(shè)置在文件系統(tǒng)superblock里，并能使用tune2fs(8)更改。
第一選擇（繼續(xù)運行）可能對包含非重要數(shù)據(jù)的系統(tǒng)管用，不過在給定的環(huán)境里讓服務(wù)器在寫入錯誤之后繼續(xù)運行，就像什么都有發(fā)生過一樣，這樣是不太好的。第三種選擇如果檢測到文件系統(tǒng)錯誤時，容易導(dǎo)致服務(wù)器到內(nèi)核的終止運行。不過，重啟可能不能修復(fù)問題，并且現(xiàn)在服務(wù)器處于可更改狀態(tài)，管理員很難知道服務(wù)器的狀況。
文件系統(tǒng)的理想設(shè)置是在檢測出錯誤時能重啟成只讀模式。這樣的話，管理員能診斷問題，采取合適的策略。重啟文件系統(tǒng)為只讀有時有一點影響，或者有時能導(dǎo)致服務(wù)器不能正常停止運行。例如，如果一臺Linux Web服務(wù)器的/var/log文件系統(tǒng)重啟為只讀，這臺服務(wù)器上的一些服務(wù)將終止功能，因為不能寫入日志。
那么所有這一切與ESX有何關(guān)系？
路徑故障問題
多數(shù)ESX安裝為了共享存儲而附屬到存儲區(qū)域網(wǎng)絡(luò)（SAN）上，并且這些服務(wù)器有多路徑的傾向。多路徑是用于維持與SAN相連的一種技術(shù)，萬一發(fā)生存儲處理器、主機總線適配器、交換機，甚至光纖通道這樣的故障時還能與SAN連接。盡管ESX利用了多路徑，不過在給定時間里只有一條路徑可用。如果路徑失效，ESX開始發(fā)送和接收所有磁盤活動到另一條路徑時會發(fā)生路徑故障。
發(fā)生路徑故障是常見的，可能一個月一次或兩次。首要問題是Linux虛擬機對ESX路徑故障如何反應(yīng)。如果發(fā)生路徑故障時，Linux虛擬機的磁盤寫入正進行一半，ESX將通知虛擬機的虛擬SCSI控制器線路繁忙，并且指示控制器等待。虛擬機決定磁盤不可訪問并有磁盤寫入故障，這引起錯誤。這個錯誤的處理將與文件系統(tǒng)所設(shè)置的“錯誤”值協(xié)調(diào)。由于在出現(xiàn)錯誤時，重啟系統(tǒng)為只讀模式逐漸成為標準做法，產(chǎn)生錯誤的文件系統(tǒng)在重啟動時就成只讀的了。只要文件系統(tǒng)不包括/var/log，那么應(yīng)該在syslog包括這個錯誤，如下所示：
SCSI Error : <0 0 0 0> return code = 0x20008
end_request: I/O error， dev sda， sector 4928181 Aborting journal on device dm-0 ext3_abort called.
EXT3-fs error (device dm-0): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only.
在經(jīng)常發(fā)生錯誤時，這種做法是合適的，因為這給管理員提供了查找事件起因的機會，以便以后不再發(fā)生此類情況。
不過使用ESX和多路徑的話，發(fā)生路徑故障的機率增加了。如果發(fā)生這樣的情況，你該作出什么反應(yīng)？
使用ESX時，在當錯誤提示重啟配置為只讀模式的話，路徑故障經(jīng)常發(fā)生。這是由于ESX和多路徑技術(shù)造成的，萬一發(fā)生某些請求故障，ESX和多路徑技術(shù)用于保持與存儲區(qū)域網(wǎng)絡(luò)的固定連接。解決這個問題有以下三種方法：
1.在一小部分Linux版本上可以下載VMware補丁修復(fù)這個問題。
2.編輯內(nèi)核源并手動安裝新內(nèi)核模塊。
3.設(shè)置虛擬機以便在發(fā)生問題時發(fā)送郵件給你，然后你可以發(fā)送郵件請求VMware給Linux打上補丁。
在上半部分中，TechTarget中國的特約虛擬化專家Andrew Kutz在發(fā)生錯誤時，Linux文件系統(tǒng)能配置成哪三種不同的模式，并且描述了為什么我們要使用第二種重啟后為只讀的模式以及這種模式在結(jié)合使用ESX 時有什么問題。本文我們將詳細解釋解決這些問題的方法。
現(xiàn)在我們來詳細講解這些選項。
選項1：執(zhí)行VMware修復(fù)
許多用戶在VMware論壇上抱怨關(guān)于路徑故障的問題，VMware必須作出反應(yīng)，所以他們?yōu)橐恍〔糠諰inux版本發(fā)布了技術(shù)基礎(chǔ)文章和解決方案?，F(xiàn)在為止，補丁所支持的Linux版本有Red Hat Enterprise Linux 3和4以及SUSE Linux Enterprise Server 9 SP3。如果你所管理的虛擬機使用的是這些操作系統(tǒng)里的一種作為子操作系統(tǒng)的話，那么可以得到在“VMware's support Web site under KB 51306”得到修復(fù)支持。
選項2：修復(fù)內(nèi)核模塊源（kernel module source）
如果你的Linux版本不屬于VMware補丁支持的范疇，也可以修復(fù)這個問題。我們可以對虛擬機隱瞞文件里發(fā)生了一個問題，以便阻止文件系統(tǒng)錯誤。
現(xiàn)在，多數(shù)裝載軟件包管理系統(tǒng)的Linux版本裝載了內(nèi)核源和內(nèi)核header包，如RPM或DEB。要修補的話，內(nèi)核源和內(nèi)核header包都要設(shè)置，因為header包里包含最新的.config文件。為了下載Ubuntu Linux源和header包，只需輸入：
sudo apt-get install linux-source-`uname -r | sed "s/-.*//g"` linux- headers-`uname -r`
更改目錄到/usr/src，這有個目錄用于存放header包，不過不存放源。你需要釋放源工具包：
tar xjf linux-source-`uname -r | sed "s/-.*//g"`.tar.bz2
用編輯器打開文件“/usr/src/linux-source- `uname -r | sed "s/-.*//g"`/drivers/message/fusion/mptscsi.h”。在739行左右出現(xiàn)下面這樣的字段：
if (scsi_status == MPI_SCSI_STATUS_BUSY)
sc->result = (DID_BUS_BUSY << 16) | scsi_status; else
sc->result = (DID_OK << 16) | scsi_status;
更換這個字段的第二行，如下所示：
if (scsi_status == MPI_SCSI_STATUS_BUSY)
// sc->result = (DID_BUS_BUSY << 16) | scsi_status;
sc->result = (DID_OK << 16) | scsi_status; else
sc->result = (DID_OK << 16) | scsi_status;
保存文件退出編輯。從header的根目錄復(fù)制.config文件到源的根目錄。更改目錄到源目錄并運行：
make oldconfig
這個命令將從復(fù)制到源目錄的header包解析.config文件，接下來的命令需要執(zhí)行一段時間：
make modules
下一步是用新內(nèi)核模式取代舊的。在這樣做之前，請確保備份了舊內(nèi)核模式，然后輸入：
cp /lib/modules/`uname -r`/kernel/drivers/message/fusion/mptscsih.ko / lib/modules/`uname -r`/kernel/drivers/message/fusion/mptscsih.ko.bak
現(xiàn)在復(fù)制新文件取代上面的：
cp /usr/src/linux-source-`uname -r | sed "s/-.*//g"`/drivers/message/ fusion/mptscsih.ko /lib/modules/`uname -r`/kernel/drivers/message/ fusion/
重啟服務(wù)器，系統(tǒng)就不再那么容易出現(xiàn)路徑故障了。
如果你運行的是Ubuntu虛擬機，內(nèi)核版本為2.6.15-28-686，想走捷徑的話繼續(xù)往下看。我已經(jīng)上傳了已修改好的源和內(nèi)核對象文件到我的網(wǎng)站上，你可以直接去網(wǎng)站下載。這個文件是mptscsih.tar.gz 選項3：Email通知
如果Linux虛擬機不受VMware補丁的支持，你也不太愿意修改內(nèi)核源的話，你至少應(yīng)該配置虛擬機，以便發(fā)生問題時你能知道。一種方法是創(chuàng)建一個腳本，每10分鐘運行一次或隨你所選。下面是一個腳本例子：
#!/bin/bash
#
# use the first argument to this script as the
# email address to send notifications to
TO="$1"
#
# get the output from the mount command
#
MOUNT_OUT=`mount`
#
# see if the string 'ro' exists in the
# output of the mount command. be careful，
# if there is a CD-ROM inserted into the
# server this will always be true and you
# will get a lot of false positives
echo $MOUNT_OUT | grep \(ro\)
#
# get the return code for the grep
# operation.
#
RO=$？
#
# grep returns an exit code
# of 0 if there is a match
#
if [ "$RO" = "0" ]
then
#
# send an e-mail notification saying
# that there is a file-system that
# has been mounted as read-only
#
BODY=$MOUNT_OUT
echo read-only file systems found
echo $BODY
`which sendmail` -f root@`hostname --fqdn` -t << FooBar
From: root@`hostname --fqdn`
To: $TO
Subject: `hostname` has read-only file systems $BODY
FooBar
#
# exit with a status code of 1 if
# read-only file systems were found
#
exit 1
fi
#
# exit with a status code of 0 if no
# read-only file systems were found
#
exit 0
安裝這個腳本，不要忘記給它一個郵箱地址。如果虛擬機的一個文件系統(tǒng)重啟為只讀時，它會提醒你，給你忽略這個問題的機會。記住，這個腳本假定你運行的是本地郵件服務(wù)器，不過也可以修改成通過中繼主機發(fā)送郵件
在發(fā)生錯誤時，Linux文件系統(tǒng)能配置成三種不同的模式：
errors=continue / errors=remount-ro / errors=panic
這三種模式分別表示忽略錯誤并只標記文件系統(tǒng)錯誤繼續(xù)運行，或者重啟系統(tǒng)為只讀，或者終止系統(tǒng)。
默認設(shè)置在文件系統(tǒng)superblock里，并能使用tune2fs(8)更改。
第一選擇（繼續(xù)運行）可能對包含非重要數(shù)據(jù)的系統(tǒng)管用，不過在給定的環(huán)境里讓服務(wù)器在寫入錯誤之后繼續(xù)運行，就像什么都有發(fā)生過一樣，這樣是不太好的。第三種選擇如果檢測到文件系統(tǒng)錯誤時，容易導(dǎo)致服務(wù)器到內(nèi)核的終止運行。不過，重啟可能不能修復(fù)問題，并且現(xiàn)在服務(wù)器處于可更改狀態(tài)，管理員很難知道服務(wù)器的狀況。
文件系統(tǒng)的理想設(shè)置是在檢測出錯誤時能重啟成只讀模式。這樣的話，管理員能診斷問題，采取合適的策略。重啟文件系統(tǒng)為只讀有時有一點影響，或者有時能導(dǎo)致服務(wù)器不能正常停止運行。例如，如果一臺Linux Web服務(wù)器的/var/log文件系統(tǒng)重啟為只讀，這臺服務(wù)器上的一些服務(wù)將終止功能，因為不能寫入日志。
那么所有這一切與ESX有何關(guān)系？
路徑故障問題
多數(shù)ESX安裝為了共享存儲而附屬到存儲區(qū)域網(wǎng)絡(luò)（SAN）上，并且這些服務(wù)器有多路徑的傾向。多路徑是用于維持與SAN相連的一種技術(shù)，萬一發(fā)生存儲處理器、主機總線適配器、交換機，甚至光纖通道這樣的故障時還能與SAN連接。盡管ESX利用了多路徑，不過在給定時間里只有一條路徑可用。如果路徑失效，ESX開始發(fā)送和接收所有磁盤活動到另一條路徑時會發(fā)生路徑故障。
發(fā)生路徑故障是常見的，可能一個月一次或兩次。首要問題是Linux虛擬機對ESX路徑故障如何反應(yīng)。如果發(fā)生路徑故障時，Linux虛擬機的磁盤寫入正進行一半，ESX將通知虛擬機的虛擬SCSI控制器線路繁忙，并且指示控制器等待。虛擬機決定磁盤不可訪問并有磁盤寫入故障，這引起錯誤。這個錯誤的處理將與文件系統(tǒng)所設(shè)置的“錯誤”值協(xié)調(diào)。由于在出現(xiàn)錯誤時，重啟系統(tǒng)為只讀模式逐漸成為標準做法，產(chǎn)生錯誤的文件系統(tǒng)在重啟動時就成只讀的了。只要文件系統(tǒng)不包括/var/log，那么應(yīng)該在syslog包括這個錯誤，如下所示：
SCSI Error : <0 0 0 0> return code = 0x20008
end_request: I/O error， dev sda， sector 4928181 Aborting journal on device dm-0 ext3_abort called.
EXT3-fs error (device dm-0): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only.
在經(jīng)常發(fā)生錯誤時，這種做法是合適的，因為這給管理員提供了查找事件起因的機會，以便以后不再發(fā)生此類情況。
不過使用ESX和多路徑的話，發(fā)生路徑故障的機率增加了。如果發(fā)生這樣的情況，你該作出什么反應(yīng)？
使用ESX時，在當錯誤提示重啟配置為只讀模式的話，路徑故障經(jīng)常發(fā)生。這是由于ESX和多路徑技術(shù)造成的，萬一發(fā)生某些請求故障，ESX和多路徑技術(shù)用于保持與存儲區(qū)域網(wǎng)絡(luò)的固定連接。解決這個問題有以下三種方法：
1.在一小部分Linux版本上可以下載VMware補丁修復(fù)這個問題。
2.編輯內(nèi)核源并手動安裝新內(nèi)核模塊。
3.設(shè)置虛擬機以便在發(fā)生問題時發(fā)送郵件給你，然后你可以發(fā)送郵件請求VMware給Linux打上補丁。
在上半部分中，TechTarget中國的特約虛擬化專家Andrew Kutz在發(fā)生錯誤時，Linux文件系統(tǒng)能配置成哪三種不同的模式，并且描述了為什么我們要使用第二種重啟后為只讀的模式以及這種模式在結(jié)合使用ESX 時有什么問題。本文我們將詳細解釋解決這些問題的方法。
現(xiàn)在我們來詳細講解這些選項。
選項1：執(zhí)行VMware修復(fù)
許多用戶在VMware論壇上抱怨關(guān)于路徑故障的問題，VMware必須作出反應(yīng)，所以他們?yōu)橐恍〔糠諰inux版本發(fā)布了技術(shù)基礎(chǔ)文章和解決方案?，F(xiàn)在為止，補丁所支持的Linux版本有Red Hat Enterprise Linux 3和4以及SUSE Linux Enterprise Server 9 SP3。如果你所管理的虛擬機使用的是這些操作系統(tǒng)里的一種作為子操作系統(tǒng)的話，那么可以得到在“VMware's support Web site under KB 51306”得到修復(fù)支持。
選項2：修復(fù)內(nèi)核模塊源（kernel module source）
如果你的Linux版本不屬于VMware補丁支持的范疇，也可以修復(fù)這個問題。我們可以對虛擬機隱瞞文件里發(fā)生了一個問題，以便阻止文件系統(tǒng)錯誤。
現(xiàn)在，多數(shù)裝載軟件包管理系統(tǒng)的Linux版本裝載了內(nèi)核源和內(nèi)核header包，如RPM或DEB。要修補的話，內(nèi)核源和內(nèi)核header包都要設(shè)置，因為header包里包含最新的.config文件。為了下載Ubuntu Linux源和header包，只需輸入：
sudo apt-get install linux-source-`uname -r | sed "s/-.*//g"` linux- headers-`uname -r`
更改目錄到/usr/src，這有個目錄用于存放header包，不過不存放源。你需要釋放源工具包：
tar xjf linux-source-`uname -r | sed "s/-.*//g"`.tar.bz2
用編輯器打開文件“/usr/src/linux-source- `uname -r | sed "s/-.*//g"`/drivers/message/fusion/mptscsi.h”。在739行左右出現(xiàn)下面這樣的字段：
if (scsi_status == MPI_SCSI_STATUS_BUSY)
sc->result = (DID_BUS_BUSY << 16) | scsi_status; else
sc->result = (DID_OK << 16) | scsi_status;
更換這個字段的第二行，如下所示：
if (scsi_status == MPI_SCSI_STATUS_BUSY)
// sc->result = (DID_BUS_BUSY << 16) | scsi_status;
sc->result = (DID_OK << 16) | scsi_status; else
sc->result = (DID_OK << 16) | scsi_status;
保存文件退出編輯。從header的根目錄復(fù)制.config文件到源的根目錄。更改目錄到源目錄并運行：
make oldconfig
這個命令將從復(fù)制到源目錄的header包解析.config文件，接下來的命令需要執(zhí)行一段時間：
make modules
下一步是用新內(nèi)核模式取代舊的。在這樣做之前，請確保備份了舊內(nèi)核模式，然后輸入：
cp /lib/modules/`uname -r`/kernel/drivers/message/fusion/mptscsih.ko / lib/modules/`uname -r`/kernel/drivers/message/fusion/mptscsih.ko.bak
現(xiàn)在復(fù)制新文件取代上面的：
cp /usr/src/linux-source-`uname -r | sed "s/-.*//g"`/drivers/message/ fusion/mptscsih.ko /lib/modules/`uname -r`/kernel/drivers/message/ fusion/
重啟服務(wù)器，系統(tǒng)就不再那么容易出現(xiàn)路徑故障了。
如果你運行的是Ubuntu虛擬機，內(nèi)核版本為2.6.15-28-686，想走捷徑的話繼續(xù)往下看。我已經(jīng)上傳了已修改好的源和內(nèi)核對象文件到我的網(wǎng)站上，你可以直接去網(wǎng)站下載。這個文件是mptscsih.tar.gz 選項3：Email通知
如果Linux虛擬機不受VMware補丁的支持，你也不太愿意修改內(nèi)核源的話，你至少應(yīng)該配置虛擬機，以便發(fā)生問題時你能知道。一種方法是創(chuàng)建一個腳本，每10分鐘運行一次或隨你所選。下面是一個腳本例子：
#!/bin/bash
#
# use the first argument to this script as the
# email address to send notifications to
TO="$1"
#
# get the output from the mount command
#
MOUNT_OUT=`mount`
#
# see if the string 'ro' exists in the
# output of the mount command. be careful，
# if there is a CD-ROM inserted into the
# server this will always be true and you
# will get a lot of false positives
echo $MOUNT_OUT | grep \(ro\)
#
# get the return code for the grep
# operation.
#
RO=$？
#
# grep returns an exit code
# of 0 if there is a match
#
if [ "$RO" = "0" ]
then
#
# send an e-mail notification saying
# that there is a file-system that
# has been mounted as read-only
#
BODY=$MOUNT_OUT
echo read-only file systems found
echo $BODY
`which sendmail` -f root@`hostname --fqdn` -t << FooBar
From: root@`hostname --fqdn`
To: $TO
Subject: `hostname` has read-only file systems $BODY
FooBar
#
# exit with a status code of 1 if
# read-only file systems were found
#
exit 1
fi
#
# exit with a status code of 0 if no
# read-only file systems were found
#
exit 0
安裝這個腳本，不要忘記給它一個郵箱地址。如果虛擬機的一個文件系統(tǒng)重啟為只讀時，它會提醒你，給你忽略這個問題的機會。記住，這個腳本假定你運行的是本地郵件服務(wù)器，不過也可以修改成通過中繼主機發(fā)送郵件