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 ESXi 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.
  
  

• The ESXi host might stop responding with a purple-diagnostic screen with messages similar to the following:
  
  @BlueScreen: #PF Exception 14 in world 4891:vmm0:HQINTSQ IP 0x41800655ea98 addr 0xcc
  41:11:55:21.277 cpu15:4891)Code start: 0x418006000000 VMK uptime: 41:11:55:21.277
  41:11:55:21.278 cpu15:4891)0x417f818df948:[0x41800655ea98]e1000_clean_tx_irq@esx:nover+0x9f stack: 0x4100b5610080
  41:11:55:21.278 cpu15:4891)0x417f818df998:[0x418006560b9a]e1000_poll@esx:nover+0x18d stack: 0x417f818dfab4
  41:11:55:21.279 cpu15:4891)0x417f818dfa18:[0x41800645013a]napi_poll@esx:nover+0x10d stack: 0x417fc68857b8
  41:11:55:21.280 cpu15:4891)0x417f818dfae8:[0x4180060d699b]WorldletBHHandler@vmkernel:nover+0x442 stack: 0x417fc67bf7e0
  41:11:55:21.280 cpu15:4891)0x417f818dfb48:[0x4180060062d6]BHCallHandlers@vmkernel:nover+0xc5 stack: 0x100410006c38000
  41:11:55:21.281 cpu15:4891)0x417f818dfb88:[0x4180060065d0]BH_Check@vmkernel:nover+0xcf stack: 0x417f818dfc18
  41:11:55:21.281 cpu15:4891)0x417f818dfc98:[0x4180061cc7c5]CpuSchedIdleLoopInt@vmkernel:nover+0x6c stack: 0x410004822dc0
  41:11:55:21.282 cpu15:4891)0x417f818dfe68:[0x4180061d180e]CpuSchedDispatch@vmkernel:nover+0x16e1 stack: 0x0
  41:11:55:21.282 cpu15:4891)0x417f818dfed8:[0x4180061d225a]CpuSchedWait@vmkernel:nover+0x20d stack: 0x410006108b98
  41:11:55:21.283 cpu15:4891)0x417f818dff28:[0x4180061d247a]CpuSched_VcpuHalt@vmkernel:nover+0x159 stack: 0x4100a24416ac
  41:11:55:21.284 cpu15:4891)0x417f818dff98:[0x4180060b181f]VMMVMKCall_Call@vmkernel:nover+0x2ba stack: 0x417f818dfff0
  41:11:55:21.284 cpu15:4891)0x417f818dffe8:[0x418006098d19]VMKVMMEnterVMKernel@vmkernel:nover+0x10c stack: 0x0
  41:11:55:21.285 cpu15:4891)0xfffffffffc058698:[0xfffffffffc21d008]__vmk_versionInfo_str@esx:nover+0xf59cc9f7 stack: 0x0
  41:11:55:21.297 cpu15:4891)FSbase:0x0 GSbase:0x418043c00000 kernelGSbase:0x0
  
  This error occurs if during cleaning of the transmit ring, the CPU is sent to perform some other tasks and if another CPU cleans the ring in the meantime, then the first CPU erroneously cleans the transit ring again and ends up de-referencing a null skb.

  
  
• 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 ESXi 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.
  
  

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 vCenter Update Manager Administration Guide.

ESXi hosts can also be updated using vSphere Host Update Utility or by manually downloading the patch ZIP file from the VMware download page and installing the bulletin by using the vihostupdate command through the vSphere CLI. For details, see the vSphere Command-Line Interface Installation and Scripting Guide and the vSphere Upgrade Guide.