ESX修复Linux虚拟机重启只读模式
当我们在服务器中检测到错误的时候,因此都会将inux服务器上的文件系统配置成重启后的只读模式,那么你知道如何配置吗?
下面我们就去看看ESX修复Linux虚拟机重启只读模式的方法。
在检测到错误时,将Linux服务器上的文件系统配置成重启后的只读模式是常见做法。
不过,这种设置在结合使用VMware VI3时可能有意想不到的结果。
在发生错误时,Linux文件系统能配置成三种不同的模式:
errors=continue / errors=remount-ro / errors=panic
这三种模式分别表示忽略错误并只标记文件系统错误继续运行,或者重启系统为只读,或者终止系统。
默认设置在文件系统superblock里,并能使用tune2fs(8)更改。
第一选择(继续运行)可能对包含非重要数据的系统管用,不过在给定的环境里让服务器在写入错误之后继续运行,就像什么都有发生过一样,
这样是不太好的。第三种选择如果检测到文件系统错误时,容易导致服务器到内核的终止运行。不过,重启可能不能修复问题,并且现在服务器处于
可更改状态,管理员很难知道服务器的状况。
文件系统的理想设置是在检测出错误时能重启成只读模式。这样的话,管理员能诊断问题,采取合适的策略。重启文件系统为只读有时有一点影响,
或者有时能导致服务器不能正常停止运行。例如,如果一台Linux Web服务器的/var/log文件系统重启为只读,这台服务器上的一些服务将终止功能,因
为不能写入日志。
那么所有这一切与ESX有何关系?
路径故障问题
多数ESX安装为了共享存储而附属到存储区域网络(SAN)上,并且这些服务器有多路径的倾向。多路径是用于维持与SAN相连的一种技术,万一
发生存储处理器、主机总线适配器、交换机,甚至光纤通道这样的故障时还能与SAN连接。尽管ESX利用了多路径,不过在给定时间里只有一条路径可用。
如果路径失效,ESX开始发送和接收所有磁盘活动到另一条路径时会发生路径故障。
发生路径故障是常见的,可能一个月一次或两次。首要问题是Linux虚拟机对ESX路径故障如何反应。如果发生路径故障时,Linux虚拟机的磁盘写入正
进行一半,ESX将通知虚拟机的虚拟SCSI控制器线路繁忙,并且指示控制器等待。虚拟机决定磁盘不可访问并有磁盘写入故障,这引起错误。这个错误的
处理将与文件系统所设置的“错误”值协调。由于在出现错误时,重启系统为只读模式逐渐成为标准做法,产生错误的文件系统在重启动时就成只读的了。
只要文件系统不包括/var/log,那么应该在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.
在经常发生错误时,这种做法是合适的,因为这给管理员提供了查找事件起因的机会,以便以后不再发生此类情况。
不过使用ESX和多路径的话,发生路径故障的机率增加了。如果发生这样的情况,你该作出什么反应?
使用ESX时,在当错误提示重启配置为只读模式的话,路径故障经常发生。这是由于ESX和多路径技术造成的,万一发生某些请求故障,ESX和多路径
技术用于保持与存储区域网络的固定连接。解决这个问题有以下三种方法:
1.在一小部分Linux版本上可以下载VMware补丁修复这个问题。
2.编辑内核源并手动安装新内核模块。
3.设置虚拟机以便在发生问题时发送邮件给你,然后你可以发送邮件请求VMware给Linux打上补丁。
![](https://js.aizhan.com/jishu/static/dlimg/201911/157294778797610.gif)
在上半部分中,TechTarget中国的特约虚拟化专家Andrew Kutz在发生错误时,Linux文件系统能配置成哪三种不同的模式,并且描述了为什么我们要使用
第二种重启后为只读的模式以及这种模式在结合使用ESX时有什么问题。本文我们将详细解释解决这些问题的方法。
现在我们来详细讲解这些选项。
选项1:执行VMware修复
许多用户在VMware论坛上抱怨关于路径故障的问题,VMware必须作出反应,所以他们为一小部分Linux版本发布了技术基础文章和解决方案。现在为止,
补丁所支持的Linux版本有Red Hat Enterprise Linux 3和4以及SUSE Linux Enterprise Server 9 SP3。如果你所管理的虚拟机使用的是这些操作系统里的一种作
为子操作系统的话,那么可以得到在“VMware's support Web site under KB 51306”得到修复支持。
选项2:修复内核模块源(kernel module source)
如果你的Linux版本不属于VMware补丁支持的范畴,也可以修复这个问题。我们可以对虚拟机隐瞒文件里发生了一个问题,以便阻止文件系统错误。
现在,多数装载软件包管理系统的Linux版本装载了内核源和内核header包,如RPM或DEB。要修补的话,内核源和内核header包都要设置,因为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行左右出现下面这样的字段:
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的根目录复制.config文件到源的根目录。www.britepic.org更改目录到源目录并运行:
make oldconfig
这个命令将从复制到源目录的header包解析.config文件,接下来的命令需要执行一段时间:
make modules
下一步是用新内核模式取代旧的。在这样做之前,请确保备份了旧内核模式,然后输入:
cp /lib/modules/`uname -r`/kernel/drivers/message/fusion/mptscsih.ko / lib/modules/`uname -r`/kernel/drivers/message/fusion/mptscsih.ko.bak
现在复制新文件取代上面的:
cp /usr/src/linux-source-`uname -r | sed "s/-.*//g"`/drivers/message/ fusion/mptscsih.ko /lib/modules/`uname -r`/kernel/drivers/message/ fusion/
重启服务器,系统就不再那么容易出现路径故障了。
如果你运行的是Ubuntu虚拟机,内核版本为2.6.15-28-686,想走捷径的话继续往下看。我已经上传了已修改好的源和内核对象文件到我的网站上,
你可以直接去网站下载。这个文件是mptscsih.tar.gz。
选项3:Email通知
如果Linux虚拟机不受VMware补丁的支持,你也不太愿意修改内核源的话,你至少应该配置虚拟机,以便发生问题时你能知道。一种方法是创建一
个脚本,每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
#
# 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
安装这个脚本,不要忘记给它一个邮箱地址。如果虚拟机的一个文件系统重启为只读时,它会提醒你,给你忽略这个问题的机会。记住,这个脚本假
定你运行的是本地邮件服务器,不过也可以修改成通过中继主机发送邮件。
在ESX上的虚拟机文件系统重启为只读时会发生问题,不过有多种方法解决这个问题。如果你还有其他问题的话,请发送邮件到editor@searchservervirtualization.com。
以上就是ESX修复Linux虚拟机重启只读模式的方法,谢谢大家一如既往的支持。
有需要服务器可以找我呢!