Knowledge Base

This patch resolves the following issues:

• A virtual machine might hang after a GuestRpc channel reinitialization. The logs might display the following message just before the virtual machine hangs:

  GuestRpc: Channel 1 reinitialized
  
  

• An excessive vob net.pg.uplink.transition.down, criteria:32 might be observed in one of the following situations:

  • When you vmotion a virtual machine on dvPort with beacon probing configured on the destination.
  • When another vmnic is added to beacon probing configured port-group.
  
  

• Space reclamation might not succeed on target LUNs due to an issue with certain vendor specific SCSI commands such as 0xc1 issued on physical RDM LUNs. This issue has been observed with NetApp SnapDrive used for space reclamation on NetApp Filers.

• When you vMotion a virtual machine with a vMotion enabled remote USB device, the USB device gets disconnected with an error message. Following is an example of the error message you might see depending on your server setup:

  Error in remoteDeviceConnect-*.log
  SSL_VerifyX509: Thumbprint mismatch for certificate with subject name:
  localhost.localdomain, 8D:35:9A:A9:E5:48:00:6F:04:6E:53:49:A0:A5:26:80:5D:BB:D1:3E
  
  

• An ESX host might fail with a purple diagnostic screen due to lack of proper synchronization during a Dentry Cache flush operation. The purple diagnostic screen might display the following:

  cpu0:4120)0x417f800c7c38:[0x418001865660]Semaphore_TryLock@vmkernel:nover+0x1b stack: 0x417f800c7c58
  cpu0:4120)0x417f800c7c78:[0x418001a2a441]DCFlushCaches@vmkernel:nover+0xb4 stack: 0x417f800c7cb8
  cpu0:4120)0x417f800c7d18:[0x41800187acd0]Timer_BHHandler@vmkernel:nover+0x203 stack: 0x100410004117550
  cpu0:4120)0x417f800c7d58:[0x418001809655]BH_Check@vmkernel:nover+0x84 stack: 0x41000409cee0
  cpu0:4120)0x417f800c7d98:[0x4180018327a4]IDT_HandleInterrupt@vmkernel:nover+0x14f stack: 0x13d791e2f102df
  cpu0:4120)0x417f800c7db8:[0x41800183302d]IDT_IntrHandler@vmkernel:nover+0xc4 stack: 0x417f800c7ec0
  cpu0:4120)0x417f800c7dc8:[0x4180018db5e7]gate_entry@vmkernel:nover+0x46 stack: 0x4018
  
  

• Public APIs that call Getrunningvms, an internal API, might display a ManagedObejectNotFound exception if the list of virtual machines it works on is not updated with the unregistered virtual machines. This might occassionally lead to disconnection from VirtualCenter Server.

  
  

• 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] < unknown> 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.

  
  

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

  
  

• The mptsas driver fails to discover dead paths when the storage controller comes back online. This issue is specifically seen with NetApp's E2600 SAS storage with firmware version 87.83.26.47.

  
  

• The vShield agent might not be uninstalled properly if you attempt to uninstall it ten days after the initial installation and without a reboot. The ESXi host, as part of a routine cleanup process, erroneously deletes some script files from the /tmp folder that are required for uninstallation.
  

• The sfcbd process is incompatible with JRE 1.6.0 Update 29 or later. When you enumerate instances from the CIM client that runs JRE 1.6.0 Update 29 or later, 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
  
  

• The IBM ULTRIUM-HH5 tape device does not support SCSI commands with ordered set attribute and might fail with a SCSI device status Check Condition and sense key 0x05/0x49/0x00 INVALID MESSAGE ERROR when SCSI requests with ordered set attribute are sent to the device.

  
  

• Reconfiguration of the virtual machine takes more than 5 minutes and the whole operation times out because of a deadlock between two hostd threads while running the DatastoreChange and reconfiguration. One of the few scenarios where this might occur is when the reconfigure task stalls in the host during disaster recovery test fail-over.

• Configuration changes made to ESXi host two days after initial installation of Cisco VEM VIBs or vShield VIBs do not persist after a system reboot. The ESXi host, as part of a routine cleanup process, erroneously deletes a state file from the /tmp folder that is required for preserving the configuration changes after reboot.

  
  

• When a remote ESXi console session is active in remote management console, the management software might timeout and the user might forget about it. This might result in an active session under the root account to the ESXi host to allow a non-ESXi privileged user who has remote management console privileges to get root access to ESXi box.

  You can now configure a session timeout to exit ESXi Tech Support Mode (TSM) as follows:

  1. Log in to Tech Support Mode as root user.
  2. Edit /etc/profile file to add TMOUT= < timeout value in seconds>
  3. Exit Tech Support Mode
     

  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.