- PR 2601778: When migrating virtual machines between vSphere Virtual Volume datastores, the source VM disks remain undeleted In certain cases, such as when a VASA provider for a vSphere Virtual Volume datastore is not reachable but does not return an error, for instance a transport error or a provider timeout, the source VM disks remain undeleted after migrating virtual machines between vSphere Virtual Volume datastores. As result, the source datastore capacity is not correct. This issue is resolved in this release.
- PR 2586088: A virtual machine cloned to a different ESXi host might be unresponsive for a minute A virtual machine clone operation involves a snapshot of the source VM followed by creating a clone from that snapshot. The snapshot of the source virtual machine is deleted after the clone operation is complete. If the source virtual machine is on a vSphere Virtual Volumes datastore in one ESXi host and the clone virtual machine is created on another ESXi host, deleting the snapshot of the source VM might take some time. As a result, the cloned VM stays unresponsive for 50 to 60 seconds and might cause disruption of applications running on the source VM. This issue is resolved in this release.
- PR 2337784: Virtual machines on a VMware vSphere High Availability-enabled cluster display as unprotected when power on If an ESXi host in a vSphere HA-enabled cluster using a vSphere Virtual Volumes datastore fails to create the .vSphere-HA folder, vSphere HA configuration fails for the entire cluster. This issue occurs due to a possible race condition between ESXi hosts to create the .vSphere-HA folder in the shared vSphere Virtual Volumes datastore. This issue is resolved in this release.
-
PR 2583029: Some vSphere vMotion operations fail every time when an ESXi host goes into maintenance mode If you put an ESXi host into maintenance mode and migrate virtual machines by using vSphere vMotion, some operations might fail with an error such as
A system error occurred:in the vSphere Client or the vSphere Web Client. In thehostd.log, you can see the following error:2020-01-10T16:55:51.655Z warning hostd[2099896] [Originator@6876 sub=Vcsvc.VMotionDst.5724640822704079343 opID=k3l22s8p-5779332-auto-3fvd3-h5:70160850-b-01-b4-3bbc user=vpxuser:<user>] TimeoutCb: ExpiredThe issue occurs if vSphere vMotion fails to get all required resources before the defined waiting time of vSphere Virtual Volumes due to slow storage or VASA provider.
This issue is resolved in this release. The fix makes sure vSphere vMotion operations are not interrupted by vSphere Virtual Volumes timeouts.
-
PR 2560998: Unmap operations might cause I/O latency to guest virtual machines
If all snapshots of a booted virtual machine on a VMFS datastore are deleted, or after VMware Storage vMotion operations, unmap operations might start failing and cause slow I/O performance of the virtual machine. The issue occurs because certain virtual machine operations change the underlying disk unmap granularity of the guest OS. If the guest OS does not automatically refresh the unmap granularity, the VMFS base disk and snapshot disks might have different unmap granularity based on their storage layout. This issue occurs only when the last snapshot of a virtual machine is deleted or if the virtual machine is migrated to a target that has different unmap granularity from the source.
This issue is resolved in this release. The fix prevents the effect of failing unmap operations on the I/O performance of virtual machines. However, to ensure that unmap operations do not fail, you must reboot the virtual machine or use guest OS-specific solutions to refresh the unmap granularity.