What's in the Release Notes

What's New

Virtual SAN 6.0 introduces many new features and enhancements. Following are the key enhancements for Virtual SAN 6.0 release:

New on-disk format: Virtual SAN 6.0 supports a new on-disk virtual file format 2.0 based on Virsto technology, which is a log-based file system that provides highly scalable snapshot and clone management support per Virtual SAN cluster.

Hybrid and all-flash configurations: Virtual SAN 6.0 supports both hybrid and all-flash cluster.

Fault domains: Virtual SAN 6.0 supports configuring fault domains to protect hosts from rack or chassis failure when the Virtual SAN cluster spans across multiple racks or blade server chassis in a data center.

Proactive Rebalance: With 6.0 release, Virtual SAN has the ability to trigger rebalance operations in order to utilize newly added cluster storage capacity.

Just a Bunch Of Disks (JBOD): Virtual SAN 6.0 supports JBOD storage for use in a blade server environment.

Disk Serviceability: Virtual SAN provides the ability to enable/disable locator LEDs from the vSphere Web Client to identify the location of storage devices during failure.

Device or Disk Group Evacuation: Virtual SAN provides the ability to evacuate data from devices and disk groups when deleting devices or disk groups.

Upgrades for This Release

Limitations

In an all-flash configuration, Virtual SAN supports a maximum write buffer cache size of 600 GB per each disk group.

For information about other maximum configuration limits for Virtual SAN 6.0 release, see the Configuration Maximums documentation.

Known Issues

After creating a virtual machine on Virtual SAN datastore, the compliance status of some VM might appear as Not Applicable
Typically, Virtual SAN storage providers are automatically registered on vCenter Server when a Virtual SAN cluster is created. During the registration, all
storage resources based on Virtual SAN policies are automatically synchronized with vCenter Server.
However, if the synchronization process fails, the compliance status of the virtual machines appear as Not Applicable because the existing storage policies references datastore capabilities that are not supported by the datastore where virtual machines reside.

Workaround: Perform the following steps to rescan the storage providers.

Browse to vCenter Server in the vSphere Web Client navigator.

Click the Manage tab, and click Storage Providers.

From the list, select the active Virtual SAN storage provider and click the Rescan the storage provider icon.

You can also restart the SPBM service.

For Linux-based vCenter Server, perform the following steps.

Log in as root through SSH.

Run the service vmware-sps restart command to restart the Profile Driven Storage Service.

Right-click the VMware vSphere Profile-Driven Storage service and click Restart.

Attempts to migrate or clone virtual machines with snapshots from Virtual SAN datastore to other datastore might fail
When you create a linked clone of a virtual machine residing on Virtual SAN that has snapshots created using the vSphere CloneVM API, such as VirtualMachineRelocateDiskMoveOptions of either createNewChildDiskBacking used for creating linked clone from Virtual SAN to non-Virtual SAN or moveChildMostDiskBacking for migration from Virtual SAN to non-Virtual SAN, where the target datastore is not Virtual SAN, the linked clone will fail

Workaround: You can remove snapshots from the base virtual machine, use Virtual SAN as the target datastore, or you can move the virtual machine from Virtual SAN to a different datastore, and then repeat the task.

Updating storage policies settings triggers too many data resynchronization tasks in the Virtual SAN cluster
After updating the following storage policies settings in the vSphere Web Client, if you browse to the Virtual SAN cluster > click the Monitor tab > Policy > Physical Disk Placement tab or run the vsan.resync_dashboard command using the RVC tool, you will see that there are too many resynchronization tasks currently in progress in the cluster for multiple objects that have been recently updated with new policy settings.

Changing the stripe width settings in the Number of disk stripes per object policy

Increasing the proportional capacity value

Changing the settings for the Number of failures to tolerate policy, when the cache reservation is set to a value greater than zero

This happens when the objects contain large amount of data that needs to be resynchronized. However, if small amount of data is found, the resynchronization tasks complete quickly without displaying any symptom.

Workaround: Wait for the resynchronization tasks to finish

Renamed tags appear as missing in the Edit VM Storage Policy wizard
A virtual machine storage policy can include rules based on datastore tags. If you rename a tag, the virtual storage policy that references this tag does not automatically update the tag and shows it as missing.

Workaround: Remove the tag marked as missing from the virtual machine storage policy, add the renamed tag, and reapply the virtual machine storage policy to all out-of-date entities.

Using the RVC tool when you run the command vsan.v2_ondisk_upgrade --allow-reduced-redundancy, the upgrade process fails at the object upgrade phase with the following error:Failed to reconfigure object version. The object is placed on one or more disks of a lower version
To upgrade the on-disk format from version 1.0 to 2.0, when you run the command, vsan.v2_ondisk_upgrade --allow-reduced-redundancy using the RVC tool, the upgrade process fails to upgrade one or more objects.

Workaround: Perform the following steps to run the upgrade command and successfully upgrade the remaining objects to 2.0.

Log in to your RVC tool.

Run the command vsan.v2_ondisk_upgrade --allow-reduced-redundancy.

Deleting a datastore tag does not automatically update the compliance status of virtual machines
You can use tags and reference them for defining storage policies for virtual machines. When a referenced tag is deleted, the compliance status of the virtual machines remains unchanged.

Workaround: None.

Restarting hosts successfully completes a previously failed task of marking disks as flash or HDD
Typically, if you attempt to mark a disk that is already added to a disk group, the task automatically fails. This happens because
in Virtual SAN, you can mark a disk as flash or HDD, only when the disk is not part of any disk group, from the vSphere Web Client,
when you navigate to the Virtual SAN cluster and click the Manage tab > Settings > Disk
Management, or when you navigate to the host > Manage > Storage > Storage devices view.
However, in this case, after you restart the host, the failed task succeeds and disk type changes.

Workaround: None.

Certain virtual machines loss compliance after you place hosts in full data migration mode
When you place a host in the full data migration evacuation mode where virtual machines are provisioned to use the force provisioning storage policy attribute, the virtual machines might lose redundancy and might not be able to tolerate the requested number of failures. For example, assume that you originally provision an object using the Number of failures to tolerate (FTT) attribute=1. When you later reconfigure the object as FTT=2 and Force provisioning=1, the object would remain at FTT=1 if Virtual SAN fails to reconfigure the object using the new policy settings.
Subsequently, if a host is evacuated using the full data migration mode, the specified object might unintentionally lose redundancy and change to FTT=0.

Workaround: If you have hosts running virtual machines that are configured to use the Force provisioning policy, make sure you do not place the hosts in Full data migration mode.

Applying a storage policy causes the Virtual SAN datastore name to appear as empty and incorrect number of fault domains being displayed in the vSphere Web Client
When the Number of failures to tolerate attribute in a VM storage policy is configured to tolerate failures greater than the number of hosts that the Virtual SAN cluster can support, the task console of the vSphere Web Client displays incorrect number of configured fault domains and the Virtual SAN datastore name appears as blank.

Workaround: None.

The virtual machine policy compliance status is not refreshed after upgrading vCenter Server
After upgrading your vCenter Server and before you finish upgrading each Virtual SAN hosts in the cluster from version 5.5 to 6.0, the storage policy compliance status for virtual machines might not get automatically refreshed. This occurs because Storage Policy Based Management (SPBM) fails to update the storage compliance status of virtual machines running in your Virtual SAN cluster during upgrade. This issue is automatically resolved after you upgrade all your hosts to 6.0.

Workaround: Restart the management agents on your ESXi host.

From the direct console, select Troubleshooting Options and press Enter.

Select Restart Management Agents and press Enter.

Press F11 to confirm the restart. The ESXi host restarts the management agents and services. Accessing this host through the vSphere Web Client and vCenter Server might temporarily lose connectivity when you restart management agents.

You can also use PuTTY or your local CLI console to restart the management agents.

Log in as a root user.

Run the /etc/init.d/vpxa restart command.

Perform the following steps if you do not want to restart the management agents on your ESXi host.

Select a storage policy that you want to edit, and click the Edit a VM Storage Policy icon.

Click Rule-Set 1, modify the existing rule, and click OK. The VM storage policy compliance status changed as Out of Date for the selected virtual machine.

Attempts to upgrade the Virtual SAN cluster to 6.0 using the RVC Tool fail with Permission denied to complete the operation
Using the RVC Tool, when you attempt to upgrade your Virtual SAN cluster from version 5.5 to 6.0, the process might fail. This usually happens during the disk format upgrade phase, when the tool attempts to evacuate data to other hosts in the cluster and finds an inaccessible object. As a result, the data evacuation fails and eventually stops the upgrade process.

Workaround: If you have inaccessible objects in the cluster, run the following command to upgrade the disk format.

The Resyncing components page displays only the resynchronization tasks for virtual machines and virtual machine templates
In the vSphere Web Client, when you navigate to the Virtual SAN cluster > click the Monitor tab > Virtual SAN > Resyncing Components, it displays only the resynchronization status for virtual machines and virtual machine templates that are currently being resynchronized. The Resyncing Components page does not display information about other objects that are also currently resynchronizing in the Virtual SAN cluster.

Workaround: None.

The Disk Management page displays different network partition group for each host in the Virtual SAN cluster
In this release, Virtual SAN introduces enhanced internode network communication protocol and a new default disk format. As a result, when a Virtual SAN cluster has a mixed environment of ESXi 5.5 and ESXi 6.0 hosts, the Virtual SAN network is automatically partitioned, and Virtual SAN places the hosts in different network partitions to avoid data corruption.

Workaround: Upgrade your ESXi hosts to 6.0. Make sure you do not add ESXi 6.0 hosts to Virtual SAN 5.5 cluster.

If the Distributed Power Management is disabled and you attempt to enable Virtual SAN on a cluster, an error message appears
You see this message even when Distributed Power Management (DPM) and Distributed Resource Scheduler (DRS) are disabled. This message might be triggered by certain previously applied settings, which are still in use.

Workaround: Perform the following steps:

Browse to the Virtual SAN cluster in the vSphere Web Client navigator.

Click the Manage tab and then click Settings.

Under Services, select vSphere DRS and click Edit.

Enable DRS, disable the Power Management option, and click OK.

(Optional) Click Edit and disable DRS.

Enable Virtual SAN again.

The Download from Datastore option does not work for virtual machine files that reside on Virtual SAN datastores
Typically, you can download virtual disks or other VM files from a datastore using the Download from Datastore option. The
option is available for any datastore when you click the Manage tab, and then click Files.
However, when triggered for a file on a Virtual SAN datastore, the download task does not complete, and its progress remain
at zero percent.

Workaround: Temporarily migrate the virtual machine to a datastore other than Virtual SAN, for example, VMFS or NFS and then download the files.

Incorrect policy compliance status is reported for powered on virtual machines that are migrated to non compliant datastore
When migrating a compliant powered on virtual machine to a noncompliant datastore, the policy compliance status of the virtual machine incorrectly reported as Compliant.

Note: If you check the compliance of a virtual machine whose host or cluster has storage policies disabled, the result of the check is Not Compliant because the feature is disabled.

Virtual machine object remains in Out of Date state even after Reapply action is triggered and completed successfully
If you edit an existing VM storage policy due to the new storage requirements, the associated virtual machine objects, home or disk, goes to an Out of Date status. Clicking the Reapply action does not change the status.
This occurs when your current environment does not support the configuration of virtual machine objects.

Workaround: Add additional resources, hosts or disks, to the Virtual SAN cluster and click Reapply again.

Virtual SAN does not display any error message when a disk failure is detected at the cluster level
A physical disk error can affect the overall performance and decrease the storage capacity of the Virtual SAN cluster. During a permanent device loss or a disk failure, Virtual SAN does not display an error message to indicate the problem.

Workaround: You can monitor the health status of your Virtual SAN hosts or disk groups by performing the following procedure:

Browse to the Virtual SAN cluster in the vSphere Web Client navigator.

On the Manage tab, click Settings.

Under Virtual SAN, click Disk Management.

Depending on your selection, you can view the status of the hosts or disk groups in the Virtual SAN Health Status column, .
The status appears as Unhealthy in the Virtual SAN Health Status column for the hosts or disk groups with a failed disk.

Compliance status of a virtual machine might not get updated when it is migrated between different types of datastores
When you migrate a virtual machine between different types of datastores, for example, Virtual SAN and VMFS, the vSphere Web Client might not update the storage compliance status of the virtual machine.

Workaround: After you migrate the virtual machine, check the storage policy compliance.

The Total capacity of Virtual SAN datastore field displays the total capacity of both healthy and unhealthy disks
When you select a Virtual SAN cluster and navigate to Manage > Virtual SAN > General, the Total capacity of Virtual SAN datastore field displays the storage capacity inclusive of both healthy and unhealthy disks, even when certain disks are unavailable or when the host is unreachable. Although the capacity of unhealthy disks is included in the total capacity, it is not available for use.

Workaround: None.

Attempts to enable fault tolerance on virtual machines that reside on a Virtual SAN datastore fail when virtual machines are not supported on the target datastore
This happens because fault tolerance is not supported for virtual machines on a Virtual SAN datastore.

Workaround: Migrate your virtual machines from the Virtual SAN datastore to another shared datastore where fault tolerance is supported.

Multiple storage policies with same name as Virtual SAN Default Storage Policy are listed in the Policies and Profiles
When you navigate to Policies and Profiles > VM Storage Policies in the vSphere Web Client, you might notice that several storage policies are using same policy name.
The default Virtual SAN default policies are predefined for each vCenter Server even if no Virtual SAN clusters are configured for these vCenter Server instances. A Virtual SAN default policy for one vCenter Server is independent from Virtual SAN default policy for another vCenter server. You can verify the assignment of default storage policies to each vCenter Server instance from the vSphere Web Client in the VC column.

Workaround: None.

The storage providers for Virtual SAN are unavailable in the Storage Providers tab
When you enable Virtual SAN on a cluster, all Virtual SAN storage providers are registered automatically. However, when you navigate to your vCenter Server in the vSphere Web Client navigator and click Manage > Storage Providers, you might not see the storage providers for Virtual SAN.

Workaround: Refresh the vSphere Web Client.

Unable to upload files to Virtual SAN datastore
Browse to the Virtual SAN datastore, click Manage > Files, click Upload a file to the datastore and attempt to upload a file, Virtual SAN initiates the upload process but stops without any progress. The file is not uploaded to the Virtual SAN datastore.

Workaround: None.

Unable to download files from the Virtual SAN datastore using the Datastore Browser
Browse to the Virtual SAN datastore, click Manage > Files, click Download from Datastore and attempt to download a file, Virtual SAN initiates the download process but stops without any progress.

Workaround: None.

Attempts to delete a storage policy fail when the resources are in use
When you attempt to delete a VM Storage Policy, that is not associated with any virtual machine, the task might fail. This happens when a VM Storage Policy is assigned as the default storage policy for a datastore.

Workaround: Assign another storage policy to the datastore by performing the following steps.

Browse to the Virtual SAN datastore whose default storage policy you want to change.

Click the Manage tab, and click Settings.

Click General, and click Edit in the Default Storage Policy pane.

From the list of available storage policies, select a policy that you want to designate as default and click OK.