VMware ESXi 6.7 - Patch Release ESXi670-202004002 - Build 16075168
Release Notes for VMware Solutions
- Audience
- Public
- Content Type
- Release Notes
- Technology Integrations
- VMware
- Source Type
- Documentation
-
PR 2458201: Some vSphere Virtual Volumes snapshot objects might not get a virtual machine UUID metadata tag During snapshot operations, especially a fast sequence of creating and deleting snapshots, a refresh of the virtual machine configuration might start prematurely. This might cause incorrect updates of the vSphere Virtual Volumes metadata. As a result, some vSphere Virtual Volumes objects, which are part of a newly created snapshot, might remain untagged or get tagged and then untagged with the virtual machine UUID. This issue is resolved in this release.
-
PR 2424969: If the first attempt of an ESXi host to contact a VASA provider fails, vSphere Virtual Volumes datastores might remain inaccessible If a VASA provider is not reachable or not responding at the time an ESXi host boots up and tries to mount vSphere Virtual Volumes datastores, the mount operation fails. However, if after some time a VASA provider is available, the ESXi host does not attempt to reconnect to a provider and datastores remain inaccessible. This issue is resolved in this release.
-
PR 2424363: During rebind operations, I/Os might fail with NOT_BOUND error During rebind operations, the source protocol endpoint of a virtual volume might start failing I/Os with a
NOT_BOUND error even when the target protocol endpoint is busy. If the target protocol endpoint is in
WAIT_RBZ state and returns a status
PE_NOT_READY, the source protocol endpoint must retry the I/Os instead of failing them. This issue is resolved in this release. With the fix, the upstream relays a BUSY status to the virtual SCSI disk (vSCSI) and the ESXi host operating system to ensure a retry of the I/O.
-
PR 2449462: You might not be able to mount a Virtual Volumes storage container due to a stale mount point If the mount point was busy and a previous unmount operation has failed silently, attempts to mount a Virtual Volumes storage container might fail with an error that the container already exists. This issue is resolved in this release.
-
PR 2467765: Upon failure to bind volumes to protocol endpoint LUNs on an ESXi host, virtual machines on vSphere Virtual Volumes might become inaccessible If a VASA provider fails to register protocol endpoint IDs discovered on an ESXi host, virtual machines on vSphere Virtual Volumes datastores on this host might become inaccessible. You might see an error similar to
vim.fault.CannotCreateFile. A possible reason for failing to register protocol endpoint IDs from an ESXi host is that the
SetPEContext() request to the VASA provider fails for some reason. This results in failing any subsequent request for binding virtual volumes, and losing accessibility to data and virtual machines on vSphere Virtual Volumes datastores. This issue is resolved in this release. The fix is to reschedule
SetPEContext calls to the VASA provider if a
SetPEContext() request on a VASA provider fails. This fix allows the ESXi host eventually to register discovered protocol endpoint IDs and ensures that volumes on vSphere Virtual Volumes datastores remain accessible.
-
PR 2429068: Virtual machines might become inaccessible due to wrongly assigned second level LUN IDs (SLLID) The nfnic driver might intermittently assign wrong SLLID to virtual machines and as a result, Windows and Linux virtual machines might become inaccessible. This issue is resolved in this release. Make sure that you upgrade the nfnic driver to version 4.0.0.44.