Knowledge Base

Summaries and Symptoms

This patch fixes the following issues:

• A memory corruption condition might occur in the virtual machine hardware. A malicious request sent from the guest operating system to the virtual hardware might 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.
  
  
  
• This change adds new error handling for configuring the VMkernel network interface, so the problem described in KB 1007249 will be avoided during initial configuration. For details of this problem, see http://kb.vmware.com/kb/1007249.
  
  
  
• When the zpool create command from a Solaris 10 virtual machine is run on a LUN that is exported as a raw device mapping (RDM) to that virtual machine, the command creates a partition table of type GPT (GUID partition table) on that LUN as part of creating the ZFS filesystem. Later when a LUN rescan is run on the ESX server through VirtualCenter or through the command line, the rescan takes a significantly long amount of time to complete because the VMkernel fails to read the GUID partition table. This patch fixes this problem.
  
  Symptoms seen without this patch: Rescanning HBAs takes a long time and an error message similar to the following is logged in /var/log/vmkernel:
  
  Oct 31 18:10:38 vmkernel: 0:00:45:17.728 cpu0:8293)WARNING: SCSI: 255: status Timeout for vml.02006500006006016033d119005c8ef7b7f6a0dd11524149442030. residual R 800, CR 80, ER 3
  
  
• This patch updates the QLogic software driver. The change includes a firmware update for QLogic 24xx fibre channel HBAs.
  
  
• This patch allows VMkernel to successfully boot on unbalanced NUMA configurations—that is, those with some nodes having no CPU or memory. When such unbalanced configuration is detected, VMkernel shows an alert and continues booting. Previously, VMkernel failed to load on such NUMA configurations.
  
  Sample alert message when memory is missing from one of the nodes (here, node 2):
  
  No memory detected in SRAT node 2. This can cause very bad performance.
  
  
• A race in LVM resignaturing code can cause volumes to disappear on a host when a snapshot is presented to multiple ESX hosts, such as in SRM environments.
  
  Symptoms: After rescanning, VMFS volumes are not visible.
  
  
• ESXi hosts crash when storage devices return large VPD 0x83 page data.
  
  When a storage device returns a VPD 0x83 page with the header indicating that the page length is greater than 255 bytes, the SCSI UID generation code attempts to access beyond the allocated buffer, resulting in a page fault.
  
  Symptoms: The ESXi host crashes (PSOD).
  
  
• Swapping active and standby NICs results in a loss of connectivity to the virtual machine. This issue is seen on systems with ESX350-200805501-BG applied.
  
  
• 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 host, and leave this virtual machine registered on two different ESX hosts.
  
  Normally if there are intermittent SAN issues, the ESX host can temporarily lose locks on the .vmdk files of the powered-on virtual machines. Usually, the ESX host times out and, after a while, reclaims the lock. The ESX host loses the lock only when the same virtual machine powers on, on another ESX host. This is an unusual occurrence. The lost lock problem happens 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 host that lost the lock to the same virtual machine currently started on the second ESX host) stops responding and becomes inaccessible, but shows as registered in both ESX hosts in VirtualCenter.
  
  With this fix, the virtual machine running on the original ESX host displays a dialog box with a message that states the locks have been lost and the virtual machine will be shutting down automatically.
  
  
• This change fixes confusing VMkernel log messages in cases where one of the storage processors (SP) of an EMC CLARiiON CX storage array is hung. The messages now correctly identify which SP is hung.
  
  Example of confusing message:
  
  vmkernel: 1:23:09:57.886 cpu3:1056)WARNING: SCSI: 2667: CX SP B is hung.
  vmkernel: 1:23:09:57.886 cpu3:1056)SCSI: 2715: CX SP A for path vmhba1:2:2 is hung.
  
  vmkernel: 1:23:09:57.886 cpu3:1056)WARNING: SCSI: 4282: SP of path vmhba1:2:2 is hung. Mark all paths using this SP as dead. Causing full path failover.
  
  In this case, research revealed that SP A was hung, but SP B was not.
  
  
• A race issue caused an ASSERT_BUG to unnecessarily run and caused the ESX host to crash. This change removes the invalid ASSERT_BUG.
  
  Symptoms seen without this patch: The ESX host crashes with an ASSERT message that includes fs3DiskLock.c:1423.
  
  Example: ASSERT /build/mts/release/bora-77234/bora/modules/vmkernel/vmfs3/fs3DiskLock.c:1423 bugNr=147983
  
  
• This change resolves a rare VMotion instability.
  
  Symptoms: During a VMotion migration, certain 32-bit applications running in 64-bit guests might crash due to access violations.
  
  
• Solaris 10 Update 4, 64-bit graphical installation fails with the default virtual machine RAM size of 512MB.
  
  
• DRS development and performance improvement. This change prevents unexpected migration behavior.
  
  
• The hostd process stops responding due to concurrency issues encountered when ESX host information is retrieved during SRM recovery.
  
  
• In a DRS cluster environment, the hostd service reaches a hard limit for memory usage, which causes hostd to restart itself.
  
  Symptoms: The hostd service restarts and temporarily disconnects from VirtualCenter. The ESX host stops responding before hostd reconnects.
  
  
• Fixes for supporting Site Recovery Manager (upcoming December 2008 release) on ESX 3.5 Update 2 and Update 3.

Deployment Considerations

None beyond the required patch bundles and reboot information listed in the table, above.

Patch Download and Installation

The typical way to apply patches to ESXi hosts is through the VMware Update Manager. For details, see the VMware Update Manager Administration Guide.

ESXi hosts can also be updated by downloading the most recent "O" (offline) patch bundle from http://support.vmware.com/selfsupport/download/ and installing the bundle using VMware Infrastructure Update or by using the vihostupdate command through the Remote Command Line Interface (RCLI). For details, see the ESX Server 3i Configuration Guide and the ESX Server 3i Embedded Setup Guide (Chapter 10, Maintaining ESX Server 3i and the VI Client) or the ESX Server 3i Installable Setup Guide (Chapter 11, Maintaining ESX Server 3i and the VI Client).

Note: ESXi hosts do not reboot automatically when you patch with the offline bundle.