Post-Trade Processing Modernization – Fast tracking the benefits of Analytics & AI while driving huge operational efficiencies Is there a financial services organization in the world who...
The FlashArray implementation of Virtual Volumes surfaces VMs on the FlashArray as standard volume groups. The volume group being named by the virtual machine name. Each VVol is then added and removed to the volume group as they are provisioned or deleted. These objects though are fairly flexible–we do not use the volume group as a unique identifier of the virtual machine–internally we use key/value tags for that.
The benefit of that design is that you can delete the volume groups, rename them, or add and remove other volumes to it. Giving you some flexibility to group related VMs or whatever your use case might be to move things around, without breaking our VVol implementation.
Well you can certainly log into the GUI and fix it. Or use our CLI. But scripting this is the best way to go, to make sure things are correct. VVols are identified by VMware via UUIDs and we offer up VVol UUIDs in our REST, which can be retrieved in any number of ways. In this example PowerShell.
In my PowerShell module:
One of the cmdlets that exists is called update-faVvolVmVolumeGroup. This takes in a few options, a VM object, a FlashArray IP/FQDN, and credentials to the FlashArray. It then goes and looks to see if a volume group exists for that VM, and if it does, if it has the right name. If it does not exist, or does not have the right name, it will create it/or rename it as needed.
PS C:UsersAdministrator> get-help update-faVvolVmVolumeGroup NAME update-faVvolVmVolumeGroup SYNOPSIS Updates the volume group on a FlashArray for a VVol-based VM. SYNTAX update-faVvolVmVolumeGroup [-vm] <VirtualMachine> [-purevip] <String> [[-faCreds] <PSCredential>] [<CommonParameters>] DESCRIPTION Takes in a VM and a FlashArray connection. A volume group will be created if it does not exist, if it does, the name will be updated if inaccurate. Any volumes for the given VM will be put into that group.
Let’s walk through some examples.
First I have a new VM called codyvm and on my array the volume group has been deleted by some no-good scoundrel.
See my VVols are not in a volume group (see one data, one config and one swap):
The VM and everything works fine, just not ideal from a GUI management perspective–so I want to recreate the volume group.
So in PowerCLI, I first connect to vCenter:
connect-viserver -Server vcenter-pure
Then store your VM in an object:
$vm = get-vm codyvm
Now import the module if it isn’t (or install it if it isn’t–see instructions on how to in the link earlier in this post).
Now enter your FlashArray credentials using get-credential.
$faCreds = Get-Credential
Finally, pipe the VM into the cmdlet and also pass in the credentials and the FlashArray FQDN/IP.
$vm |update-faVvolVmVolumeGroup -purevip flasharray-x70-b.purecloud.com -faCreds $faCreds
The cmdlet will create the volume group, add the volumes to it, and then return all of the new names of the volumes that have been put into the volume group:
On the FlashArray you can see the new volume group:
Another situation is if I rename the VM. I want to update the volume group.
So I change “codyvm” to “codyvmnewname”. If I rerun the same cmdlet as above it will update the volume group name.
NOTE: This also comes in handy in vSphere 6.7 Update 1. There is a change in how VMware formulates the API calls to VASA for VM creation where we do not get the VM name where we expect, so the volume group does not get created. We are updating our VASA provider to react to this change, but in the mean time for new VMs created in that release, you will need to run this cmdlet to get the volume group created.