Troubleshooting, Tips, and Best Practices
Troubleshooting VMware VVol datastores on Unity
This section describes possible issues and workarounds, limitations, and things to be aware of when deploying VVol datastores on the storage system. For a detailed list of system limits, refer to the Simple Support Matrix on the support site. For a complete list of all issues, refer to the Release Notes.
Failed to deploy VM to a VVol datastore of sufficient size
When deploying virtual volumes to VVol datastores on the storage system, the virtual volume files take up additional overhead beyond the size of the VMDK itself (data-vvol). This overhead can lead to failures when deploying new VMs to VVol datastores, even though the combined vDisk sizes are less than the overall size of the VVol datastore. This is especially true when VMs are powered on (swap-vvol) and has snapshots (memory-vvol).
For example, if the VVol datastore is 50 GB and currently has a virtual volume that is 25 GBs, attempting to deploy a new virtual volume of 20 GBs may fail due to the overhead.
It is recommended that you reserve 10-20% of the VVol datastore size as free space.
VVols inaccessible after registering a second vCenter
If a second vCenter server registers the Unity system as a VASA provider when there is already a registered vCenter, this may cause the VVol datastores to be inaccessible and thus VM operations to fail. To change vCenters, unmount all datastores and unregister the VASA provider from the original vCenter before registering the system as a VASA provider for the new vCenter.
Alternatively, to use multiple vCenters with Unity, you should deploy Platform Services Controller (PSC) as a separate appliance (refer to the VMware documentation for details: http://blogs.vmware.com/vsphere/2015/03/vcenter-server-6-topology-ha.html). You can then install multiple vCenter appliances and configure them all to use the same PSC. In this configuration, each vCenter uses the same PSC CA certificate allowing you to register Unity as the VASA Provider on multiple vCenter servers.
File VVol creation failure—Failed to create directory
When deploying a File VVol in vSphere and the VMware limit of eight maximum NFS datastore mounts is exceeded, vSphere returns a vague error message such as:
Cannot complete file creation operation.Operation failed, diagnostics report: Hostsvc::osfs::CreateDirectory : Failed to create directory new-vm1 (Cannot Create File.
This error message is less intuitive than the vSphere error that displays when deploying an NFS datastore that exceeds this limit: NFS has reached the maximum number of supported volumes.
For instructions on increasing the limit of eight maximum NFS mounts in vSphere, refer to the following VMware Knowledge Base article: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2239
VVols changes fail during an SP reboot
VVol changes made in vSphere may appear to have failed when Unity has an SP reboot..
Some VVol operations initiated through vSphere, such as SPBM migrations, may appear to fail if there is a concurrent SP reboot on the Unity system. This occurs because during an SP reboot, VASA is temporarily unavailable. Errors such as the following may display in vSphere:
The ESXi VVol session is invalid.
Task was rolled back and marked as failed. This is because some tasks failed or SP rebooted during task execution.
Restart the vSphere operation once the Unity system comes back online after the SP reboot.
VVol operations time out under high stress loads
With high-stress workloads where many VMs are created/booted in parallel, such as a bootstorm in a VDI environment, sporadic timeouts of VVols operations may occur. This is more likely to occur on arrays that use NL-SAS system drives.
Adjust the settings in vSphere to reduce the number of possible concurrent VVols operations.
VMware Certificate Authority (VMCA) support
In vSphere 6.0 and later, there are three different modes for how the Certificate Authority (CA) provisions certificates for ESXi hosts and vCenter servers:
- Using the VMCA (default).
- Using the VMCA as a subordinate CA to a custom certificate authority.
- Using a custom CA as the direct root CA.
The Unity system supports only the default configuration where the VMCA provisions certificates as the root certificate authority. ESXi hosts and vCenter servers are authenticated by ensuring that the client certificate presented to the array has been signed by a trusted CA, which must be the VMCA for Unity systems.
Refer to the following VMware article for more details on CA modes for vSphere 6.0 and later:
VMware Horizon support
The current Unity VVol implementation has not yet been fully certified for use with VMware Horizon View for Virtual Desktop Infrastructure (VDI). It is recommended that you use VDI and Unity when deploying less than 500 desktops.