Do and Don't - VVol

    VVol been out and supported for a while now, with Nimble OS 3.x offering support for VVol I thought this will be a good time to write up about key operations one should look out for when implementing VVol with a NImble array.

     

    The Nimble array offers many features for the Storage Admin that needed to wear additional hats so VI admin, some operations had to be performed on multiple platforms and interfaces.

    VVol offers to offload this duty from us and allow us to manage the VM with full insight to the Nimble OS features directly from the vSphere UI.

     

    This changes many best practices and many day to day operations that we do, the following list is some ideas of operations that we do today for other integrations such VMFS and traditional VMs and how we should perform them with the VVol integration.

     

    • Volume operations from the Nimble array UI
      • With VVol in mind all operations should now be done from the vSphere UI and communicated back to the array via the VASA provider.
      • The following operations should be avoided
        • Volume offline.
        • Volume delete.
        • Volume location in a folder.

     

    • Access to a volume
      • Access to the VVol volume is set by the VASA provider when we create the VVol VM, the access is set to the host. Removing initiators groups from the volume access tab might cause the VVol VM to become inaccessible to the host and to the end user.
        • Avoid adding or removing initiator groups in the volume access tab.

     

    • Initiator groups used by VVol volume
      • The initiator groups used by VVol VMs are created by the Nimble VMware plugin during the registration of the plugin, we expect a certain conditions to be met when using those, such 1-1 mapping ( one initiator in one initiator group).
        • Avoid editing the initiators names / identifiers in the initiator group.
        • Avoid removing the initiators from the initiator group.
        • Avoid Adding initiators to the initiator group.
        • The Nimble array limit the initiator group name to 64 characters, the name is constructed from the initiators IQN.
          • Long IQN names should be avoided.

     

    • Protection of a VVol VM
      • Protection to a VVol VM should be set from within the vSphere UI by using SPBM, this operation allow the VASA provider to communicated volume collection membership, protection schedule and so on.
        • Avoid creating a volume collection for the VVol volumes
          • This is done for you by the VASA provider and the SPBM.
        • Avoid moving VVol volumes from the VASA provider created volume collection to an array side created volume collection.
        • Avoid setting VMware sync’d snapshot on the VVol volume collection.
          • VMware does not support such operation at the moment.

     

     

    We should note, that as the vCenter is the point of registration with the Nimble Storage VASA Provider, we don't recommend hosting a vCenter VM on a VVol datastore, in case of connectivity issues or a vCenter down for any reason, any management of a VVol datastores will become difficult.

     

    Whilst the list above might look a bit daunting, the best advice I can give you is manage VVol from the vSphere UI, SPBM is your best friend and we're here to help if needed

     

     

    Doing more with less – VVols and Simplified Storage Management

    Nimble Storage Integration with VVols

    NimbleOS 3 - Introduction To Folders

    Talk VVol2.0 and VASA3 to me

     

     

    Thanks,

    Moshe.

    @Moshe_Blumberg