Note:
Purity//FA should be upgraded to 5.3.16+ or 6.1.8+ before upgrading to vSphere 7.0 U3 to U3b. There is a critical issue that was re-introduced with the release of vSphere 7.0 U3 and U3a that will cause duplicate vVol IDs when vSphere takes managed snapshots of vVols based VMs on the FlashArray. Prior to upgrading the vSphere environment to 7.0 U3 or higher, please work with Everpure support to confirm that all FlashArrays using vVols are upgraded to Purity//FA 5.3.16+ or 6.1.8+
While not a vVols or VASA specific bug or fix, it's a crucial fix as vVols can only be Thin Provisioned on the FlashArray.
- PR 2861632: If a guest OS issues UNMAP requests with large size on thin provisioned VMDKs, ESXi hosts might fail with a purple diagnostic screen ESXi 7.0 Update 3 introduced an uniform UNMAP granularity for VMFS and SEsparse snapshots, and set the maximum UNMAP granularity reported by VMFS to 2GB. However, in certain environments, when the guest OS makes a trim or unmap request of 2GB, such a request might require the VMFS metadata transaction to do lock acquisition of more than 50 resource clusters. VMFS might not handle such requests correctly. As a result, an ESXi host might fail with a purple diagnostic screen. VMFS metadata transaction requiring lock actions on greater than 50 resource clusters is rare and can only happen on aged datastores. The issue impacts only thin-provisioned VMDKs. Thick and eager zero thick VMDKs are not impacted.