• Troubleshooting, Tips, and Best Practices

    PDF

    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 EMC Online Support. 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

    The Unity storage system can only be registered as a VASA provider for one vCenter server at a time. If a second vCenter server registers the Unity system as a VASA provider, this will cause the VVol datastores to be inaccessible, causing VM operations to fail.

    Do not attempt to register the Unity system with a second vCenter server. 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.

    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 mount 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

    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:

    1. Using the VMCA (default).
    2. Using the VMCA as a subordinate CA to a custom certificate authority.
    3. 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:

    https://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.security.doc/GUID-4D658104-1D80-441D-B6BA-4CBBCD0EDD3C.html

    Unity VVol datastores do not support full VVol datastore isolation between independent vSphere components using the VASA control path.

    VMware Horizon support

    The current Unity VVol implementation has not yet been fully certified for use with VMware Horizon View. Although it may work, it is recommended that you do not deploy VDI desktops using Unity VVol datastores. Support and issue resolution will not be available for this integration.