Summaries and Symptoms
This patch resolves the following issues:
- If you hot-add a child disk to a virtual machine, and the path to the parent disk is different than the virtual machine's home directory, the virtual machine unexpectedly stops working, powers off, and you cannot power it on again. The issue does not reproduce if you hot-add a child disk and you do not specify the path, or just specify the datastore to which the child disk belongs.
-
When the Dump file set is called using the esxcfg-dumppart or other commands multiple times in parallel, an ESXi host might stop responding and display a purple diagnostic screen with entries similar to the following as a result of a race condition while dump block map is freed up:
@BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4907 - Corruption in dlmalloc
Code start: 0xnnnnnnnnnnnn VMK uptime: 234:01:32:49.087
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]PanicvPanicInt@vmkernel#nover+0x37e stack: 0xnnnnnnnnnnnn
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Panic_NoSave@vmkernel#nover+0x4d stack: 0xnnnnnnnnnnnn
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DLM_free@vmkernel#nover+0x6c7 stack: 0x8
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Heap_Free@vmkernel#nover+0xb9 stack: 0xbad000e
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Dump_SetFile@vmkernel#nover+0x155 stack: 0xnnnnnnnnnnnn
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]SystemVsi_DumpFileSet@vmkernel#nover+0x4b stack: 0x0
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_SetInfo@vmkernel#nover+0x41f stack: 0x4fc
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_Set@ <none></none># <none></none>+0x394 stack: 0x0
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@ <none></none># <none></none>+0xb4 stack: 0xffb0b9c8
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0x0
0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry_@vmkernel#nover+0x0 stack: 0x0
-
When a VMDK is configured with I/O filters, and the guest OS issues a successful SCSI unmap commands, it is possible that the SCSI unmap command is sucessful although one of the I/O filters might fail the operation. As a result, the state of the VMDK and the filter diverges and can result in data corruption.
-
The ESXi SNMP agent crashes randomly and triggers false host reboot alarms in the SNMP monitoring station. For stateful ESXi hosts the core dump is located in the
/var/core directory, and the
syslog.log file contains
out of memory error messages. For stateless ESXi hosts, see Knowledge Base Article
1032051. The issue results in loss of monitoring of the host.
-
In an environment with Nutanix NFS storage, the secondary Fault Tolerance VM fails to take over when the primary Fault Tolerance VM is down. The issue occurs when an ESXi host does not receive a response of a CREATE call within a timeout period. After you apply this patch, you can configure the CreateRPCTimeout parameter by running the following command:
esxcfg-advcfg -s 20 /NFS/CreateRPCTimeout
Note: As the host profile does not capture the CreateRPCTimeout parameter, the value of CreateRPCTimeout is not persistent in stateless environments.
-
In order to update the last seen time stamp for each LUN on an ESXi host, a process has to acquire a lock on
/etc/vmware/lunTimestamps.log file. The lock is being held for a long time than necessary in each process. If there are too many such processes trying to update the
/etc/vmware/lunTimestamps.log file, they might result in lock contention on this file. If hostd is one of these processes that is trying to acquire the lock, the ESXi host might get disconnected from the vCenter Server or become unresponsive with lock contention error messages (on
lunTimestamps.log file) in the hostd logs. You might get a similar error message:
Error interacting with configuration file /etc/vmware/lunTimestamps.log: Timeout while waiting for lock, /etc/vmware/lunTimestamps.log.LOCK, to be released. Another process has kept this file locked for more than 30 seconds. The process currently holding the lock is <process_name>(<PID>). This is likely a temporary condition. Please try your operation again.Note:
- process_name is the process or service that is currently holding the lock on the /etc/vmware/lunTimestamps.log. For example, smartd, esxcfg-scsidevs, localcli, etc.
- PID is the process ID for any of these services.
Deployment Considerations
None beyond the required patch bundles and reboot information listed in the table above.
Patch Download and Installation