How can I use ESX to repair the read-only mode of Linux Virtual Machine restart?

Article Title: How to Use ESX to repair the read-only mode of Linux Virtual Machine restart ?. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

When an error is detected, it is common to configure the file system on the Linux server to the read-only mode after restart. However, this setting may have unexpected results when combined with VMware VI3.

When an error occurs, the Linux File System can be configured with three different modes:

Errors = continue/errors = remount-ro/errors = panic

The three modes indicate ignore errors and only mark file system errors to continue running, restart the system as read-only, or terminate the system.

The default setting is in the file system superblock and can be changed using tune2fs (8.

The first option (continue to run) may work for systems that contain non-important data. However, in a given environment, the server can continue to run after an error is written, just as if everything has happened, this is not good. Third, if a file system error is detected, it may easily cause termination of running from the server to the kernel. However, restarting the server may not be able to fix the problem, and the server is now in a changeable state. It is difficult for the Administrator to know the status of the server.

The ideal setting of the file system is to reset the read-only mode when an error is detected. In this way, the administrator can diagnose the problem and adopt appropriate policies. Restarting the file system is read-only, which sometimes has a slight impact, or may cause the server to stop running normally. For example, if the/var/log file system of a Linux Web server is restarted as read-only, some services on this server will terminate the function because logs cannot be written.

So what is the relationship between all this and ESX?

　　Path faults

Most ESX installations attach to a storage Region network (SAN) for shared storage, and these servers tend to have multiple paths. Multi-path is a technology used to maintain SAN connection. It can also be connected to SAN in the event of a fault such as a storage processor, host bus adapter, switch, or even Fiber Channel. Although ESX uses multiple paths, only one path is available at a given time. If the path is invalid, path failure occurs when ESX starts to send and receive all disk activity to another path.

Path faults are common and may occur once or twice a month. The primary issue is how Linux virtual machines respond to ESX path faults. If a path failure occurs, the disk write of the Linux virtual machine is half done, ESX notifies the virtual SCSI controller of the virtual machine that the line is busy and instructs the Controller to wait. The Virtual Machine determines that the disk is inaccessible and there is a disk write failure, which causes an error. The handling of this error will be consistent with the "error" value set by the file system. When an error occurs, restarting the system becomes a standard practice in read-only mode, and the file system that causes the error becomes read-only when it is restarted. As long as the file system does not include/var/log, this error should be included in syslog, as shown below:

SCSI Error: <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.

This approach is appropriate when errors occur frequently, because it provides administrators with the opportunity to find the cause of the event so that such a situation will not occur in the future.

However, If ESX and multi-path are used, the probability of path failure increases. What should you do if this happens?

When ESX is used, path faults often occur when an error is prompted to restart the configuration to read-only mode. This is due to ESX and multi-path technology. In the event of certain request failures, ESX and multi-path technology are used to maintain a fixed connection with the storage area network. There are three ways to solve this problem:

1. In a few Linux versions, you can download the VMware patch to fix this problem.

2. Edit the kernel source and manually install the new kernel module.

3. Set up a VM to send an email to you when a problem occurs. Then, you can send an email requesting VMware to patch Linux.

[1] [2] Next page