One of the common questions I’m asked with regards to VVols on Pure Storage is “Can I rename the Data Volume on the FlashArray? If I do, what happens?”. Now, why would you want to rename the volume on the array? When Virtual Volumes are provisioned on the FlashArray they are given a “hash” that is part of the automated process. Something like “Config-72a520db”. This is part of the automated creation and configuration of a VVol VM or individual VMDK being provisioned for a VVol VM.
Just at a glance, I don’t know which one of those Data Volumes is VMDK 1 or VMDK 2. The next question, “If everything is automated with VVols, what does it matter if I know which VMDK that Data volume represents?”. Which is a very good question. In the majority of cases the end user will never need to know what FlashArray Data Volume lines up with the exact VMDK. However, what if you need to restore that VMDK from a snapshot or import a RDM or Physical Volume to that VVol VM? It’s still possible, but you would still need to know what VMDK you are overwriting. Likely you’d end up using the sizes of the data volumes to know what VMDK they are for.
What if there are several Data Volumes of the same size? That’ll make things a little more difficult. Luckily with the Pure Storage vSphere web client plugin it can make life a little easier. From vCenter navigate to the VM then go to the FlashArray Virtual Volumes Objects tab. Here you can see that VMDK number and then see the name of the FlashArray Volume.
From the information there I know that VMDK 1 is the array volume “Data-3a10aaa8” and VMDK 2 is the array volume “Data-02925f4e”. What happens when I rename or update the FlashArray Volumes?
The FlashArray volumes are renamed, time to look at the FlashArray objects tab in the vCenter web client.
I was able to map the VMDK to FlashArray Volume as well as rename the FlashArray Volumes and see what happened afterwards. While this works fine for a few VMs this wouldn’t scale all that well with multiple VMs. For now PowerCLI is the best bet to get this information. Cody Hosterman put together a nice blog post on tracking this, found here. I know that Cody and myself are looking at putting together a better way to build out this information and there should be some more information on that coming in the future.
This post was really just showing what happens when the data vvol is renamed on the FlashArray and how that “could” help make a logical mapping of VMDK to FlashArray Volume easier. Odds are that you won’t have to map out these VMDK to FlashArray Volumes with the automation of VVols combined with the FlashArray web client plugin.