Knowledge Base

Summaries and Symptoms

This patch provides updates to fix multiple security issues in the service console kernel. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2010-0291, CVE-2010-0307, CVE-2010-0622, CVE-2010-1087, CVE-2010-1437, CVE-2010-1088, CVE-2010-0415, and CVE-2010-3081 to these issues.

This patch also fixes the following issues:

• vCenter Server does not trigger an alarm when one of the NICs in a team loses connectivity. The issue occurs when the number of vSwitches, portgroups per vSwitch, uplinks per vSwitch, or physical NICs is more than 16 on the ESX host.
  
  
• Hot-add operation might fail when you try to hot-add memory or CPU to a virtual machine whose reserved memory or CPU is more than half the available physical memory or CPU of the host machine. After applying this patch, hot-add might fail sometimes when the available physical memory on an ESX host is less than twice the overhead memory of the virtual machine.
  To view the available physical memory or CPU in vSphere Client, select an ESX host and click the Resource Allocation link. The available physical memory is displayed under Memory > Available Capacity. The available CPU is displayed under CPU > Available Capacity.
  To view the overhead memory of a virtual machine, select the virtual machine and click the Resource Allocation link. The overhead memory is displayed under Memory > Overhead.
  
  
• On blade servers that are running ESX, vCenter Server incorrectly reports the service tag of the blade chassis instead of that for the blade. On a Dell or IBM blade server that is managed by vCenter Server, the service tag number is listed in the System section in vCenter Server under Configuration > Processors. This issue occurs due to the incorrect value of the Fixed CIM OMC_Chassis instance SerialNumber property.
  
  
• For ESX running on BULL servers, vSphere Client uses numbers starting from 96 as suffixes for names of Processor and Power sensors. For example, Processor 96 or PowerSupply 97. With this patch, the Processor and Power sensor names start with Processor 0 or PowerSupply 1.
  
  
• On Fujitsu PRIMERGY servers, sfcbd process starts using more CPU than the expected 40-60%. The /var/log/sdr_content.raw and /var/log/sel.raw files might contain the text efefefefefefefefefefefef, and /var/log might contain a SDR response buffer was wrong size message.
  This issue occurs because IpmiProvider might use CPU for a long time to process meaningless text similar to efefef.
  
  
• When you run the esxtop command to monitor ESX performance, the result shows incorrect values such as 3.26088E+18 or 3.10982E+12 for disk access frequently. This issue occurs when heavy disk I/O is in progress, or when you suspend or resume virtual machines.
  
  
• VMware Tools fails after you install it on a virtual machine running Solaris 10. This issue occurs when you have VMXNET3 device enabled or have guest VLAN configured with e1000g device on your machine. This issue occurs on Solaris 10 Update 4 and later guest operating systems.
  
  
• The esxcfg-volume utility might fail to mount VMFS volumes with snapshots, and result in an error message similar to the following:
  Error: Unable to resignature this VMFS3 volume due to duplicate extents found
  If you dynamically add capacity from the storage device to the VMFS datastore and perform a VMFS rescan operation, the VMFS volumes on ESX hosts might not mount under /vmfs/volumes/ when you use the esxcfg-volume utility. This issue might occur due to dynamic expansion of snapshot volumes from storage having multiple extents. With this patch, ESX improves handling for multiple partitions or devices in VMFS volumes.
  
  
• When you connect ESX 4.0 Update 2 (with port binding enabled) to an iSCSI SAN that is connected from a different subnet and configured on the same VLAN, you might see the following error message in the VMkernel log file:
  iSCSI connection is being marked "OFFLINE"
  If you are using multiple VMkernel portgroups for iSCSI traffic on ESX 4.0 Update 2 with port binding enabled, you might see twice the number of paths to the iSCSI targets on ESX 4.0 Update 2 compared to the number of paths on ESX 4.0 Update 1.
  
  
• The swap file of a virtual machine is equal in size to the configured memory after completion of storage vMotion. After a virtual machine running with memory reservation is moved to a different datastore using storage vMotion, the host creates a swap file equal in size to the configured memory. The vmware.log file of the virtual machine might contain messages similar to the following:
  May 25 16:42:38.756: vmx| FSR: Decreasing CPU reservation by 750 MHz, due to atomic CPU reservation transfer of that amount. New reservation is 0 MHz.FSR: Decreasing memory reservation by 20480 MB, due to atomic memory reservation transfer of that amount. New reservation is 0 pages. CreateVM: Swap: generating normal swap file name.
  When ESX hosts perform storage vMotion, the swap file size of virtual machines increases to memsize. With this fix, the swap file size remains the same after storage vMotion.
  
  
• Linux virtual machines with VMXNET2 virtual NIC might fail when the virtual machines are using MTU greater than the standard MTU of 1500 bytes (jumbo frames).
  
  
• The ESX host fails and displays a purple screen while accessing files on corrupted VMFS volume.
  
  
• ESX host might fail and display a purple screen when you try to access any LUN that is removed from the system but was detected by the ESX host through rescanning the SAN or performing NMP claiming tasks, and simultaneously if you are listing the devices in the VMFS (/vmfs/device/disks) by running the ls -l command. This issue might also occur when you export system logs and simultaneously list the devices under VMFS. The issue occurs because when one thread has removed the device attribute structure of the device, another thread might be trying to read it.
  
  
• If VMware Tools that is downloaded from ESX 3.5 or later is installed on Windows virtual machines that are configured with the automatic VMware Tools upgrade option, automatic upgrade to ESX 4.0 VMware tools on these virtual machines might fail with an error message similar to the following:
  Error upgrading VMware Tools.
  
  
• When you create a snapshot of a virtual machine, the snapshot does not reflect CPU and memory resource settings of the parent virtual machine. Features such as linked clones that are based on snapshots might not capture the resource settings due to this issue.
  

Deployment Considerations

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

Patch Download and Installation

See the VMware vCenter Update Manager Administration Guide for instructions on using Update Manager to download and install patches to automatically update ESX 4.0 hosts.

To update ESX 4.0 hosts when not using Update Manager, download the patch ZIP file from http://support.vmware.com/selfsupport/download/ and install the bulletin using esxupdate from the command line of the host. For more information, see the ESX 4 Patch Management Guide.