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.
Note you should be on at least the 188.8.131.52 version of the module to do everything listed in this post.
PS C:\Users\cody> 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>] [[-datastore] <Datastore>] [[-flasharray] <PureArray>] [<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. RELATED LINKS REMARKS To see the examples, type: "get-help update-faVvolVmVolumeGroup -examples". For more information, type: "get-help update-faVvolVmVolumeGroup -detailed". For technical information, type: "get-help update-faVvolVmVolumeGroup -full".
Let’s walk through some examples.
First I have a new VM called App08 and on my array the volume group has been deleted by some no-good scoundrel.
My VVols are not in a volume group (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 app08
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 create a connection to your FlashArray
$fa = new-pfaarray -EndPoint <FlashArray IP/FQDN> -UserName <user name> -Password <password> -IgnoreCertificateError
Finally, pipe the VM into the cmdlet and also pass in the credentials and the FlashArray FQDN/IP.
$vm |update-faVvolVmVolumeGroup -flasharray $fa
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.
The cmdlet also works at scale. The VM input can also be an array of VMs like below:
PS C:\Users\Administrator> $vm = get-vm -Name "vm-*" PS C:\Users\Administrator> $vm Name PowerState Num CPUs MemoryGB ---- ---------- -------- -------- vm-0016 PoweredOn 4 16.000 vm-0014 PoweredOn 4 16.000 vm-0017 PoweredOn 4 16.000 vm-0013 PoweredOn 4 16.000 vm-0019 PoweredOn 4 16.000 vm-0011 PoweredOn 4 16.000 vm-009 PoweredOn 4 16.000 vm-0018 PoweredOn 4 16.000 vm-000 PoweredOn 4 16.000 vm-006 PoweredOn 4 16.000 vm-0015 PoweredOn 4 16.000 vm-0012 PoweredOn 4 16.000 vm-002 PoweredOn 4 16.000 vm-004 PoweredOn 4 16.000 vm-007 PoweredOn 4 16.000 vm-003 PoweredOn 4 16.000 vm-005 PoweredOn 4 16.000 vm-001 PoweredOn 4 16.000 vm-0010 PoweredOn 4 16.000 vm-008 PoweredOn 4 16.000
So I am storing all of those VMs in a variable and then I can pass it to the cmdlet either through pipline:
$vm | update-faVvolVmVolumeGroup -flasharray $fa
Or through the parameter:
update-faVvolVmVolumeGroup -flasharray $fa -vm $vm
Another option is a whole datastore, if I want to update the volume groups for all of the VMs on a given VVol datastore, I can instead just pass in the datastore.
$datastore = get-datastore FlashArray-VVolDS-FA1 update-faVvolVmVolumeGroup -flasharray $fa -datastore $datastore
You have the option to pipeline it in as well:
$datastore | update-faVvolVmVolumeGroup -flasharray $fa
If you pass in a non-Pure, non-VVol datastore it will fail the process. Also if you pass in an array of VMs and one or more is either not a VVol VM, or not on that specified FlashArray, it will be skipped.
The last thing to note is that is returns the names of all of the volumes it affected, so store the response in a variable if you want to then do something to those volumes:
$volumes = $datastore | update-faVvolVmVolumeGroup -flasharray $fa $volumes vvol-vm-0012-FF6FFE58-vg/Config-0b28c59e vvol-vm-0012-FF6FFE58-vg/Data-592f7f3c vvol-vm-0012-FF6FFE58-vg/Swap-10cc12a0 vvol-vm-0014-C2EC5EE9-vg/Config-4b7e5f7d vvol-vm-0014-C2EC5EE9-vg/Data-93cd7b04 vvol-vm-0014-C2EC5EE9-vg/Swap-5b708bf7 vvol-vm-0016-21AC193D-vg/Config-fded266e vvol-vm-0016-21AC193D-vg/Data-ed504825 vvol-vm-0016-21AC193D-vg/Swap-bd37efb2
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. This is fixed in Purity 5.1.9. If you are running 6.7 U1 or later update to this release.