ESX Server 3.0.2, Patch ESX-1006980: Virtual Machine Is Powered On, on Multiple ESX Server Hosts; VMkernel Mark Paths as Offline When SVC Is Not Ready After a SVC Reset (1006980)
Intermittent network and intermittent SAN issues occurring at the same time might result in conditions like unreachable SAN or high latencies. This situation might cause HA to power on the same virtual machine on a second ESX Server host, and leave this virtual machine registered on two different ESX hosts. Normally if there are intermittent SAN issues, the ESX Server host can temporarily lose locks on the .vmdk files of the powered on virtual machines. Usually, the ESX Server host times out and, after a while, reclaims the lock. The ESX Server host loses the lock only when the same virtual machine powers on, on another ESX Server host. This is an unusual occurrence. The lock is lost only when there are network issues that make HA restart virtual machines on another host. So, if there are intermittent network and intermittent SAN issues, the virtual machine (which is running on the original ESX Server host that lost the lock to the same virtual machine currently started on the second ESX Server host) stops responding and becomes inaccessible, but shows as registered in both ESX Server hosts in the VirtualCenter Server. With this fix, the virtual machine running on the original ESX Server host displays a dialog box with a message that states the locks have been lost and the virtual machine will be shutting down automatically.
After an IBM SAN Volume Controller (SVC) is reset, it returns a Check Condition 2/0 0x2 0x4 0xc error code while SVC synchronizes cache with the partner node. With this fix, VMkernel marks this path as offline to cause a failover and use paths of another node (a node that is not reset) to send I/O data.
- A memory corruption condition may occur in the virtual machine hardware. A malicious request sent from the guest operating system to the virtual hardware may cause the virtual hardware to write to uncontrolled physical memory. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2008-4917 to this issue.
Download and verify the patch bundle as follows:
- Download patch ESX-1006980 from http://www.vmware.com/download/vi/vi3_patches.html.
- Log in to the ESX Server service console as root.
- Create a local depot directory.
# mkdir -p /var/updates
Note: VMware recommends that you use the updates directory.
- Change your working directory to /var/updates.
# cd /var/updates
- Download the tar file into the /var/updates directory.
- Verify the integrity of the downloaded tar file:
# md5sum ESX-1006980.tgz
The md5 checksum output should match the following:
- Extract the compressed tar archive:
# tar -xvzf ESX-1006980.tgz
- Change to the newly created directory, /var/updates/ESX-1006980:
# cd ESX-1006980
# esxupdate update
To run esxupdate from a different directory, you must specify the bundle path in the command:
# esxupdate -r file://<directory>/ESX-1006980 update
For example, if the host is called depot:
# esxupdate -r file:///depot/var/updates/ESX-1006980 update
During the update process, logs appear on the terminal. You can specify the verbosity of esxupdate logs by using the -v option as shown, below.
# esxupdate -v 10 file://<directory>/ESX-1006980 update
For more information on how to use esxupdate, see the Patch Management for ESX Server 3 tech note at http://www.vmware.com/pdf/esx3_esxupdate.pdf.