Search the VMware Knowledge Base (KB)
View by Article ID

VMware ESXi 4.0, Patch ESXi400-201203401-SG: Updates Firmware (2011777)

  • 1 Ratings


Release date: March 30, 2012

Patch Classification Security
See KB 2014447 if using Update Manager 5.0
Build For build information, see KB 2011768.
Host Reboot Required Yes
Virtual Machine Migration or Shutdown Required Yes
PRs Fixed 719473, 730272, 731391, 744551, 751343, 769745, 770876, 771604, 778209, 784595, 787649, 792344, 793140, 818429, 818649, and 827800
Affected Hardware N/A
Affected Software N/A
Related CVE numbers CVE-2012-1515


Summaries and Symptoms

This patch resolves the following issues:

  • After you install VMware Tools on a virtual machine with the Windows NT 4.0 operating system, the vSphere Client displays the VMware Tools status as VMware Tools: Out of date instead of Ok.

  • In an environment with two powered on virtual machines on the same ESXi host that reference a shared VMDK, attempts to revert to a snapshot on either virtual machine might fail and the vSphere Client might display a File lock error. This issue occurs with both VMFS and NFS datastores.

  • An ESXi host broadcasts large number of Reverse Address Resolution Protocol (RARP) packets simultaneously after the unicast address of the port client is changed. This patch resolves this issue by timing the RARP broadcasting in a timer to avoid excessive RARP packets.

  • When you restart a virtual machine that is connected to a vSwitch and is on an active NIC with the teaming parameter Failback set to No, the setting is not retained, and the NIC teaming function incorrectly puts the virtual machine on a standby NIC.

  • Upgrade from ESXi 4.0.x to ESXi 4.1 using VMware Update Manager might fail on IBM x3650 M2 servers with an error message similar to the following:
    Software or system configuration of <host name> is incompatible. Check scan results for details.

  • When you create snapshots or power on virtual machines that have Changed Block Tracking (CBT) enabled, the ESXi host might fail and display a purple diagnostic screen that contains messages similar to:
    @BlueScreen: #PF Exception 14 in world 7530035:hostd-worker IP 0x41803b9c9faa addr 0x41008ffffff8
    cpu2:7530035)Code start: 0x41803b400000 VMK uptime: 56:01:21:36.256
    cpu2:7530035)0x417f8319f9e8:[0x41803b9c9faa]COWGetLayout@esx:nover+0x119 stack: 0x417ffb418f40
    cpu2:7530035)0x417f8319fb08:[0x41803b9cd567]COW_Ioctl@esx:nover+0x336 stack: 0x183
    cpu2:7530035)0x417f8319fb98:[0x41803b63932c]DevFSIoctl@vmkernel:nover+0x5cf stack: 0x417f8319fbd8
    cpu2:7530035)0x417f8319fbe8:[0x41803b61d320]FSS_IoctlByFH@vmkernel:nover+0x97 stack: 0x417ffbd59e40
    cpu2:7530035)0x417f8319fc88:[0x41803bbb2c93]CBT_Ioctl@esx:nover+0x3ca stack: 0x41000b400040
    cpu2:7530035)0x417f8319fd18:[0x41803b63932c]DevFSIoctl@vmkernel:nover+0x5cf stack: 0x410004f4dab0
    cpu2:7530035)0x417f8319fd58:[0x41803b61d3a9]FSS_Ioctl@vmkernel:nover+0x5c stack: 0x1b380018def5
    cpu2:7530035)0x417f8319fe88:[0x41803b580080]UserFileIoctl@vmkernel:nover+0x4ef stack: 0x417f8319ffc0
    cpu2:7530035)0x417f8319fec8:[0x41803b58a3d7]LinuxFileDesc_Ioctl@vmkernel:nover+0x82 stack: 0xdf
    cpu2:7530035)0x417f8319ff18:[0x41803b564dc5]User_LinuxSyscallHandler@vmkernel:nover+0xf8 stack: 0x2de3f6b8
    cpu2:7530035)0x417f8319ff28:[0x41803b4da747]gate_entry@vmkernel:nover+0x46 stack: 0x0
    cpu2:7530035)FSbase:0x0 GSbase:0x418040800000 kernelGSbase:0x2de40b90

  • When you log in to Direct Console User Interface (DCUI) and change the keyboard layout by using the Configure Keyboard option to anything other than Default, the keyboard layout is changed accordingly. After a system reboot, although the Configure Keyboard option in DCUI displays the keyboard layout type as configured earlier, the keyboard might still function like a Default keyboard.

  • An ESXi host generates excessive Reverse Address Resolution Protocol (RARP) packets when virtual machines join or leave multicast groups.

  • An attempt to delete a file from a directory with more than 468 files or delete the directory itself might fail, and the ESXi host might erroneously report that the VMFS is corrupted.The ESXi host logs error messages similar to the following to the /var/log/messages file:
    cpu10:18599)WARNING: Fil3: 10970: newLength 155260 but zla 2
    cpu10:18599)Fil3: 7054: Corrupt file length 155260, on FD <70, 93>, not truncating

  • Multiple threads compete during task deactivation in the ESXi software iSCSI initiator. This might cause ESXi to become unresponsive and display a purple diagnostic screen that contains messages similar to:
    cpu2:4098)0x417f800179b8:[0x41800da85e31]vmk_SPUnlock@vmkernel:nover+0x0 stack: 0x0
    cpu2:4098)0x417f80017a78:[0x41800e22a86b]iscsivmk_TaskHandleTx@esx:nover+0x46 stack: 0x4100be04c490
    cpu2:4098)0x417f80017ac8:[0x41800e22acaf]iscsivmk_ConnProcessTxSchQueue@esx:nover+0x116 stack: 0x417f80017b00
    cpu2:4098)0x417f80017bc8:[0x41800e22b72e]iscsivmk_ProcessWorldletConnTxEvent@esx:nover+0x3ad stack: 0x417fce2
    cpu5:5012)0x417f81ca7b98:[0x41800da8bd0f]vmk_SPLock@vmkernel:nover+0x12 stack: 0x0
    cpu5:5012)0x417f81ca7bd8:[0x41800e19c051]iscsivmk_TransportStopConn@esx:nover+0xbc stack: 0x0
    cpu5:5012)0x417f81ca7c78:[0x41800df4e285]iscsitrans_HandleEvent@esx:nover+0x790 stack: 0x417f81ca7cb4
    cpu5:5012)0x417f81ca7ce8:[0x41800df4f6d2]iscsitrans_VmklinkCallback@esx:nover+0x169 stack: 0x41000000001d
    cpu5:5012)0x417f81ca7d38:[0x41800dbbdd28]VmkApiLinkSocketCallback@vmkernel:nover+0x53 stack:

    This issue might occur due to the following reasons:
    1. The task management thread attempts to abort a task, while the transmit thread attempts to take up the same task for data transmission.
    2. A task attempts completion normally while the task's connection is being closed.

  • If an sfcbd process receives fatal signal and goes into debug mode, the sfcbd process stops responding and cannot be restarted. When the sfcbd-watchdog process queries CIM instances to monitor sfcbd status, the ESXi host might continuously log CIM error messages similar to the following to the /var/log/messages file:
    prop_of_instances: CIM error: enumInstances CURL error: 7
    root: sfcbd-watchdog:failed query: /bin/prop_of_instances root/cimv2 OMC_RegisteredBaseServerProfile

    prop_of_instances: CIM error: enumInstances CURL error: 7
    root: sfcbd-watchdog:failed query: /bin/prop_of_instances root/interop CIM_IndicationFilter CreationClassName
    prop_of_instances: CIM error: enumInstances CURL error: 7
    root: sfcbd-watchdog:failed query: /bin/prop_of_instances root/cimv2 OMC_RegisteredBaseServerProfile

    root: sfcbd-watchdog:stopping sfcbd
    root: sfcbd Stopping sfcbd
    root: sfcbd-watchdog:starting sfcbd
    root: sfcbd Starting sfcbd

  • An ESXi host that is up and running for more than a year results in an integer overflow in a VMkernel variable. Such an integer overflow causes the ESXi host to fail and display a purple diagnostic screen that contains messages similar to the following:
    @BlueScreen: #PF Exception(14) in world 1056477182:sh ip 0x41803645e7fc addr 0x417ff5d1e50c
    LBR: from 0x41803645e825 to 0x41803645e7e1
    Code starts at 0x418036400000
    0x4100c7ff7d08:[0x41803645e7fc]WorldNewInt+0xa3 stack: 0x4100a30e4bf0
    0x4100c7ff7d38:[0x41803645ec6f]World_New+0xbe stack: 0xbad0014
    0x4100c7ff7d98:[0x41803645ee0e]WorldNewDefaultWorld+0x179 stack: 0x4100c7ff7e08
    0x4100c7ff7de8:[0x41803657ae50]UserCartel_NewChildWorld+0x9b stack: 0x4100c7ff7e48
    0x4100c7ff7e38:[0x41803657af5d]UserCartel_Fork+0xc8 stack: 0x4100c7ff7e78
    0x4100c7ff7ef8:[0x41803656369d]LinuxThread_Clone+0x134 stack: 0xec7ff7f28
    0x4100c7ff7f28:[0x41803653d90c]User_LinuxSyscallHandler+0xa3 stack: 0x0
    VMK uptime: 376:06:20:51.393 TSC: 69176487691905272
    FSbase (0x0) GSbase (0x5e3fbc80) kernelGSbase (0x0)

  • When you use an ESXi host for Virtual Desktop Infrastructure (VDI) deployment, hostd might fail and cause the ESXi host to become unresponsive.

  • In an environment that uses be2net driver with multiple physical network interface controllers, if vmnic1 and vmnic1x are be2net, then a reboot or unload of the be2net module might cause the ESXi host to fail with a purple diagnostic screen similar to the following:
    @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4758 - Usage error in dlmalloc0: cpu8:4169)Code start: 0x41801aa00000 VMK uptime:
    cpu8:4169)0x417f8024fe40:[0x41801aa58816]Panic@vmkernel:nover+0xa9 stack: 0x4100b2680040
    cpu8:4169)0x417f8024fe60:[0x41801aa1918b]DLM_free@vmkernel:nover+0x602 stack: 0x4100a1c67010
    cpu8:4169)0x417f8024fe90:[0x41801aa282bb]Heap_Free@vmkernel:nover+0x7a stack: 0x4100b5a11d60
    cpu8:4169)0x417f8024feb0:[0x41801af74a7c]be_cleanup_procfs@esx:nover+0xdf stack: 0x87418216d
    cpu8:4169)0x417f8024fef0:[0x41801af70a46]benet_close@esx:nover+0x1bd stack: 0x417f00000020
    cpu8:4169)0x417f8024ff30:[0x41801ae67432]dev_close@esx:nover+0x99 stack: 0x41000528de60
    cpu8:4169)0x417f8024ff50:[0x41801ae67500]CloseNetDev@esx:nover+0x7f stack: 0x410005209af8
    cpu8:4169)0x417f8024ff90:[0x41801aafcc77]UplinkProcessAsyncCallsHelperCB@vmkernel:nover+0x122 stack: 0x417f80
    cpu8:4169)0x417f8024fff0:[0x41801aa2a51f]helpFunc@vmkernel:nover+0x53e stack: 0x0
    cpu8:4169)0x417f8024fff8:[0x0] stack: 0x0
    cpu8:4169)FSbase:0x0 GSbase:0x418042000000 kernelGSbase:0x0
    cpu9:4173)UserCartel: 1454: bootstrap/init UW died (0)
    cpu19:20463)UserLinux: 917: Restarting the system

    This might also occur with vmnic2 and vmnic2x and other higher-ordered nics.

  • The sfcbd process is incompatible with JRE 1.6.0 Update 29 and later versions. When you enumerate instances from the CIM client that runs JRE 1.6.0 Update 29 or later version, the CIM client might display CIM error messages similar to the following:
    IN:HTTP/1.1 501 Not Implemented
    Fri Nov 18 09:17:01 IST 2011:
    HTTPException: HTTP Method Not Implemented (500)
    Fri Nov 18 09:17:01 IST 2011:
    httpe exception occurred
    Fri Nov 18 09:17:01 IST 2011:
    Sending a POST request.
    Fri Nov 18 09:17:01 IST 2011:
    POST Method not implemented on the server: null

This patch also resolves the following security issue:

  • A flaw in the way port-based I/O is handled might allow an attacker to modify the Virtual DOS Machine ROM and escalate privileges on virtual machines that run the following guest operating systems:
    • Windows 2000
    • Windows XP 32-bit
    • Windows Server 2003 32-bit
    • Windows Server 2003 R2 32-bit
    The Common Vulnerabilities and Exposures project ( has assigned the name CVE-2012-1515 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 CLI Installation and Reference Guide and the vSphere Upgrade Guide.

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.


  • 1 Ratings

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.

What can we do to improve this information? (4000 or fewer characters)

Please enter the Captcha code before clicking Submit.
  • 1 Ratings