| VMware vSAN 8.0 Update 3| 25 JUN 2024| ISO Build 24022510 Check for additions and updates to these release notes. |
What's in the Release Notes
These release notes introduce you to new features in VMware vSAN 8.0 Update 3 and provide information about known issues.
What's New
vSAN 8.0 Update 3 introduces the following new features and enhancements:
-
Licensing
Capacity-based licensing. The subscription-based licensing in VMware Cloud Foundation 5.2 entitles customers to 1 Tebibyte (TiB) of vSAN capacity per VCF core license, with additional capacity available through a capacity-based add-on license.
-
Flexible Topologies
Stretched cluster support on vSAN ESA. In VMware Cloud Foundation 5.2 vSAN Express Storage Architecture fully supports stretched cluster topologies. This enables VCF to configure workload and management domains that provide site-level resilience for your workloads and data.
vSAN Max as principal storage. VCF 5.2 supports vSAN Max as primary, centralized shared storage. This enables VCF to configure workload domains with disaggregated vSAN Max clusters, in addition to aggregated vSAN HCI clusters, to increase your flexibility.
vSAN File Services up to 250 file shares. vSAN 8.0 Update 3 improves the scalability of native File Services in VMware Cloud Foundation by increasing the number of shares per cluster to 250 on vSAN ESA.
-
Data Protection
vSAN local data protection leveraging ESA scalable snapshots. vSAN data protection enables you to capture local snapshots using an intuitive new UI, and store them on your vSAN datastore. Use protection groups to easily define VM membership, snapshot schedules, retention, and immutability criteria for VMs. You can use these snapshots to revert, restore, recover, or clone VMs for enhanced levels of protection.
Integration with VMware Live Cyber Recovery (VLCR), for faster ransomware recovery. vSAN data protection integration with VMware Live Cyber Recovery (VLCR), captures point-in-time snapshots for cloud-based ransomware protection, and VLCR provides the tools to protect data off-site and recover VMs in an isolated recovery environment (IRE) for analysis before restoring them on-premises. VLCR uses a local snapshot, and only updates the changes (deltas) from IRE to production, drastically reducing restore times.
-
Improved Resiliency
Congestion remediation. vSAN 8.0 Update 3 enhances vSAN OSA's ability to detect and remediate various types of congestion early, preventing cluster-wide I/O latencies.
Adaptive delete congestion. vSAN now provides adaptive delete congestion for compression-only disk groups in vSAN OSA, improving IOPS performance and delivering more predictable application responses.
-
Enhanced Management
Proactive hardware management. vSAN 8.0 Update 3 introduces a new method for collecting critical storage device telemetry from preferred server vendors, enabling predictive management of hardware issues. Proactive Hardware Management leverages OEM vendors' predictive failure monitoring tools integrated into vCenter via API (after OEM Hardware Support Manager is setup and configured), to help you make more informed decisions about hardware maintenance.
Data-at-rest encryption disable for vSAN ESA. You can disable data-at-rest encryption on vSAN ESA clusters at any point after enabling it. vSAN ESA now supports the following operations for data-at-rest encryption: enable encryption, disable encryption, shallow rekey, and deep rekey.
Customizable alarm thresholds for NVMe storage devices in vSAN ESA. vSAN 8.0 Update 3 enables you to customize alert thresholds for device endurance, tailoring them to specific clusters, hosts, disk vendors, or even individual devices.
vSAN I/O Trip Analyzer cluster level view. vSAN 8.0 Update 3 enables you to run performance analysis on multiple VMs simultaneously. You can select up to 8 VMs at once, and quickly perform analysis on each selected VM.
Enhanced awareness of vSAN Max using Aria Operations. VMware Cloud Foundation Operations with VCF 5.2 introduces enhanced visibility for vSAN Max clusters throughout its user interface. This enables Aria Operations to track resource utilization and health status.
Federated vSAN health monitoring in Aria Operations. The latest Aria Operations introduces federated vSAN cluster health monitoring for clusters spanning across multiple vCenters.
VMware vSAN Community
Use the vSAN Community Web site to provide feedback and request assistance with any problems you find while using vSAN.
Product Support Notices
-
Deprecation of locales:
Beginning with the next major release, we will be reducing the number of supported localization languages. The three supported languages will be:
-
Japanese
-
Spanish
-
French
The following languages will no longer be supported:
-
Italian, German, Brazilian Portuguese, Traditional Chinese, Korean, Simplified Chinese
Impact:
-
Users who have been using the deprecated languages will no longer receive updates or support in these languages.
-
All user interfaces, help documentation, and customer support will be available in the three supported languages mentioned above.
-
Upgrades for This Release
For instructions about upgrading vSAN, see the VMware vSAN 8.0 Update 3 documentation.
Note: Before performing the upgrade, please review the most recent version of the VMware Compatibility Guide to validate that the latest vSAN version is available for your platform.
vSAN 8.0 Update 3 is a new release that requires a full upgrade to vSphere 8.0 Update 3. Perform the following tasks to complete the upgrade:
-
Upgrade to vCenter Server 8.0 Update 3. For more information, see the VMware vSphere 8.0 Update 3 Release Notes.
-
Upgrade hosts to ESXi 8.0 Update 3. For more information, see the VMware vSphere 8.0 Update 3 Release Notes.
-
Upgrade the vSAN on-disk format to version 20.0. If upgrading from on-disk format version 3.0 or later, no data evacuation is required (metadata update only).
-
Upgrade FSVM to enable new File Service features and get all the latest updates.
Note: vSAN retired disk format version 1.0 in vSAN 7.0 Update 1. Disks running disk format version 1.0 are no longer recognized by vSAN. vSAN will block upgrade through vSphere Update Manager, ISO install, or esxcli to vSAN 7.0 Update 1. To avoid these issues, upgrade disks running disk format version 1.0 to a higher version. If you have disks on version 1.0, a health check alerts you to upgrade the disk format version.
Disk format version 1.0 does not have performance and snapshot enhancements, and it lacks support for advanced features including checksum, deduplication and compression, and encryption. For more information about vSAN disk format version, see KB 2148493.
Upgrading the On-disk Format for Hosts with Limited Capacity
During an upgrade of the vSAN on-disk format from version 1.0 or 2.0, a disk group evacuation is performed. The disk group is removed and upgraded to on-disk format version 17.0, and the disk group is added back to the cluster. For two-node or three-node clusters, or clusters without enough capacity to evacuate each disk group, select Allow Reduced Redundancy from the vSphere Client. You also can use the following RVC command to upgrade the on-disk format: vsan.ondisk_upgrade --allow-reduced-redundancy
When you allow reduced redundancy, your VMs are unprotected for the duration of the upgrade, because this method does not evacuate data to the other hosts in the cluster. It removes each disk group, upgrades the on-disk format, and adds the disk group back to the cluster. All objects remain available, but with reduced redundancy.
If you enable deduplication and compression during the upgrade, you can select Allow Reduced Redundancy from the vSphere Client.
Limitations
For information about maximum configuration limits for the vSAN 8.0 Update 3 release, see the Configuration Maximums documentation.
Known Issues
-
vSAN ESA: Scheduled snapshots missing in Snapshots list
Some processing operations can cause a VM in a data protection group to miss a scheduled snapshot. This is expected behavior, and does not affect future scheduled snapshots.
Workaround: None.
-
vSAN ESA: Data protection does not activate if VM has vSphere snapshots
This issue occurs when you take a vSphere snapshot of a VM before vSAN takes any data protection snapshots. vSAN data protection cannot be activated for the VM, and vSAN does not take any scheduled or manual vSAN snapshots.
Workaround: Delete the vSphere snapshot.
-
Failed vCenter Server tasks while creating vSAN File share at high concurrency
While creating vSAN File Shares at high concurrency (more than 32 threads), the vCenter Server tasks may fail with the Operation not allowed in current state error. This error does not impact the back end executions and the corresponding host tasks can succeed.
Workaround: Verify the health status of the created file shares using the vSAN health check. Close the current vCenter Server session and open a new session.
-
vSAN File Service does not support NFSv4 delegations
vSAN File Service does not support NFSv4 delegations in this release.
Workaround: None.
-
In stretched cluster, file server with no affinity cannot rebalance
In the stretched cluster vSAN File Service environment, a file server with no affinity location configured cannot be rebalanced between Preferred ESXi hosts and Non-preferred ESXi hosts.
Workaround: Set the affinity location of the file server to Preferred or Non-Preferred by editing the file service domain configuration.
-
Deleting files in a file share might not be reflected in vSAN capacity view
The allocated blocks might not be returned back to the vSAN storage instantly after all the files are deleted and hence it would take some time before the reclaimed storage capacity to be updated in vSAN capacity view. When new data is written to the same file share, these deleted blocks might get reused prior to returning them to vSAN storage.
If unmap is enabled and vSAN deduplication is disabled, the space may not be freed back to vSAN unless 4MB aligned space are freed in VDFS. If unmap is enabled and vSAN deduplication is enabled, space freed by VDFS will be freed back to vSAN with a delay.
Workaround: To release the storage back to vSAN immediately, delete the file shares.
-
vSAN allows a VM to be provisioned across local and remote datastores
vSphere does not prevent users from provisioning a VM across local and remote datastores in an HCI Mesh environment. For example, you can provision one VMDK on the local vSAN datastore and one VMDK on remote vSAN datastore. This is not supported because vSphere HA is not supported with this configuration.
Workaround: Do not provision a VM across local and remote datastores.
-
Power Off VMs fails with Question Pending
If a VM has a pending question, you are not allowed to do any VM-related operations until the question is answered.
Workaround: Try to free the disk space on the relevant volume, and then click Retry.
-
vSAN OSA: In deduplication clusters, reactive rebalancing might not happen when the disks show more than 80% full
In deduplication clusters, when the disks display more than 80% full on the dashboard, the reactive rebalancing might not start as expected. This is because in deduplication clusters, pending writes and deletes are also considered for calculating the free capacity.
Workaround: None.
-
Host failure when converting data host into witness host
When you convert a vSAN cluster into a stretched cluster, you must provide a witness host. You can convert a data host into the witness host, but you must use maintenance mode with Full data migration during the process. If you place the host into maintenance mode with Ensure accessibility option, and then configure it as the witness host, the host might fail with a purple diagnostic screen.
Workaround: Remove the disk group on the witness host and then re-create the disk group.
-
Duplicate VM with the same name in vCenter Server when residing host fails during datastore migration
If a VM is undergoing storage vMotion from vSAN to another datastore, such as NFS, and the host on which it resides encounters a failure on the vSAN network, causing HA failover of the VM, the VM might be duplicated in the vCenter Server.
Workaround: Power off the invalid VM and unregister it from the vCenter Server.
