Knowledge Base

Summaries and Symptoms

This patch resolves the following issues:

• VMware Tools might fail to upgrade to a newer version of VMware Tools detected on ESX host when the virtual machine is set with the Check and upgrade Tools during power cycling option.
  
  
• The MAC address generated for vmknic used a fixed 4 bytes value as hash prefix, which increased the chances of MAC address conflict. This patch resolves the issue by using the dynamic NIC ID string as prefix to generate vmknic MAC addresses. Before the fix, the generated vmknic MAC addresses were always prefixed with 0050567. After the fix, the prefix is 0050566.
  
  
• A race condition between the i18n layer and the AutostartManager class might cause the host to stop responding. This issue might occur when you perform vMotion or storage vMotion operations on Juniper vGW security appliances.
  
  
• Log entries to check the maximum number of open file descriptors of sfcb processes are added. You can check the limits for open file descriptors in the cim logs by performing the following steps:
  
  
  1. Set the CIM log level to 6 by running the # esxcfg-advcfg -s 6 /UserVars/CIMLogLevel command.
     
  2. Restart the sfcbd service by using the # /etc/init.d/sfcbd-watchdog restart command.
  
  Verify that the log file in the /var/log/messages folder contains entries similar to the following for the maximum limits for open file descriptor:
  
  sfcb-HTTP-Daemon[30847]: --- Limit of maximum open file descriptors: soft Limit - 512 Hard Limit - 1024
  
  
• Linux virtual machines that use the VMXNET3 driver might experience network throughput degradation when they are connected to Traffic Shaping enabled Distributed vSwitch.
  
  
• When you use the esxtop utility in batch mode, the virtual disk data reported in the csv file might be incorrect.
  
  
• An ESX host might fail with a purple diagnostic screen and reports a PF Exception error with backtrace similar to:
  
  @BlueScreen: #PF Exception 14 in world 137633099:vmm0:TSTSPSR IP 0x41801e20b01f addr 0x0
  cpu4:137633099)Code start: 0x41801dc00000 VMK uptime: 464:10:04:03.850
  cpu4:137633099)0x417f86a5f6b8:[0x41801e20b01f]COWCopyWriteDone@esx:nover+0x122 stack: 0x41027f520dc0
  cpu4:137633099)0x417f86a5f6e8:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x0
  cpu4:137633099)0x417f86a5f968:[0x41801e20b2c2]COWAsyncDataDone@esx:nover+0x125 stack: 0x41027f5aebd8
  cpu4:137633099)0x417f86a5f998:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x41027f556ec0
  cpu4:137633099)0x417f86a5f9c8:[0x41801dc085e9]AsyncCompleteOneIO@vmkernel:nover+0xac stack: 0x41027fd9c540
  cpu4:137633099)0x417f86a5f9f8:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x41027f5ae440
  cpu4:137633099)0x417f86a5fa18:[0x41801de240b9]FS_IOAccessDone@vmkernel:nover+0x80 stack: 0x41027f556858
  cpu4:137633099)0x417f86a5fa48:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x41027f59a2c0
  cpu4:137633099)0x417f86a5fa78:[0x41801dc085e9]AsyncCompleteOneIO@vmkernel:nover+0xac stack: 0x41027f480040
  cpu4:137633099)0x417f86a5faa8:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x417f86a5fad8
  cpu4:137633099)0x417f86a5fad8:[0x41801de3fd1d]FDSAsyncTokenIODone@vmkernel:nover+0xdc stack: 0x0
  cpu4:137633099)0x417f86a5fbd8:[0x41801de4faa9]SCSICompleteDeviceCommand@vmkernel:nover+0xdf0 stack: 0x41027f480040
  
  
• The VMware vSphere API contains a denial of service vulnerability. This issue allows an unauthenticated user to send a maliciously crafted API request and disable the host daemon. Exploitation of the issue would prevent management activities on the host but any virtual machines running on the host would be unaffected.
  
  VMware would like to thank Sebastián Tello of Core Security Technologies for reporting this issue to us.
  
  The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2012-5703 to this issue.
  
  
• During installation or uninstallation of VMware Tools in SLES 11, the original file permission that is set for /etc/fstab is not retained.
  
  
• Attempts to uninstall VMware Tools in RHEL 6.x virtual machine aborts with the following error:
  
  Unable to find the answer INITRDMODS_CONF_VALS in the installer database
  

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.1 hosts.

To update ESX 4.1 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.1 Patch Management Guide.