One of the great benefits of vVols is that fact that virtual disks are just volumes on your array. So this means if you want to do some data management with your virtual disks, you just need to work directly on the volume that corresponds to it.

The question is what virtual disk corresponds to what volume on what array?

Well some of that question is very array dependent (are you using Pure Storage or something else). But the first steps are always the same. Let’s start there for the good of the order.

Since VVols are still a fairly new concept for most, let’s review some basics.

A vVol

A vVol is a volume on the array that VMware uses for some purpose to represent a VM or store information related to a VM. This could be the home directory information, a virtual disk, snapshots, or more.

How this is represented on the array varies, but at the basic level it is a volume on an array that is also managed by VMware.

Config vVol

Every vVol VM has at least one config vVol. A config vVol holds the home directory information of the VM. This is 4 GB in size and holds files like a VMX file, or logs, or VMDKs, or snapshot hierarchies.

Data vVol

Every time you create a virtual disk, a VMDK pointer file is created in the config vVol and a corresponding volume is created on the array. VMware does not format the data vVol in any way.

vVol Datastore

A vVol datastore is often best defined by what it is not. It is not a file system, it is not a volume, it is not a disk. It is a capacity quota from a given array. When you create a VM in it, a config vVol is created on the array that “owns” that vVol datastore and that config vVol is associated with it. So when you right click (for instance) on a vVol datastore and choose “Browse files” you will see folders. These folders are just links that redirect you the config vVol. When you browse a folder on a vVol datastore, you are actually looking inside of a config vVol. When you move to a different folder, you are moving to a different config vVol.

Okay that’s the basics.

vVol UUID

The first thing to understand about any vVol is that they are all assigned a UUID. This gets assigned when the volume on the array is created. This value is stored on the array (more on that later) and is then also stored inside of the VMDK pointer file (in the case of a data vVol for instance).

So when VMware needs to do something to a virtual disk that is a vVol (resize, delete, reconfigure, etc), VMware gets the UUID and then provides it to the array and the array finds the volume that has that UUID and performs the requested action.

So the nice thing about this is VMware usually does most of this work by communicating this exchange via VASA.

But what if you want to do some peripheral to what VMware can do. Like take a vVol volume and copy it to some other volume. Or report on the average latency. Or whatever?

Well that stuff needs to be done on the array. You can make “eyeball” matches in the GUI, look for the name of the VM, find the corresponding volume in the VM (in the case of the FlashArray the corresponding volume in the volume group that represents the VM) and click away. But that method does not stand up to any level of programmatic scrutiny.

The first step is to get the UUID. There two main types of vVols config vVols and data vVols. Let’s start off with data vVols as this is a bit more straight forward.

In the part 3 of this series, we will then look at what to do on the FlashArray to actually find the volume once you have the UUID.

Finding the Data vVol UUID

The best way to do this is to use the Pure Storage PowerShell VMware Module:

install-module PureStorage.FlashArray.VMware
connect-viserver <vCenter>
$vm = get-vm <VM nanme>
$vm |get-harddisk | get-vvolUuidFromHarddisk

This will return all of the data vVol UUIDs to you:

If you want just one, just pass in one:

How do I do that? Well: First off, I have a VM with 3 vVol virtual disks:

I want to know the UUID of the second virtual disk, called hard disk 2.

I will grab my VM with get-vm:

The next step is to get the disk from the VM. This can be easily achieved by piping the VM into the get-harddisk cmdlet. I will then store my desired virtual disk in $disk:

Now to get the UUID. The UUID can be found in the extension data of the virtual disk under the backing information. The property in there called backingObjectId is the one you want.

This value can come in a few syntactic forms, the form it takes is up to your storage vendor. Most will be in one of the two formats:

RFC 4122 128-bit format with prefix, “rfc4122.xxxxxxxx‐xxxx‐xxxx‐xxxx‐xxxxxxxxxxxx”

NAA 128‐bit UUID with prefix, “naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”

The X’s are all in hex. Some vendors might go with a 64 bit size as well, but in general, 128-bit is used.

So for this particular virtual disk, the corresponding vVol UUID is rfc4122.f403f740-326e-483d-9618-c9d62b04f7c8.

One thing to note, that this value will be a blank string “” for VMFS-based virtual disks and will be null for RDMs. So if you do not get a result, it means the virtual disk is not a vVol.

Finding the Config vVol UUID

So that’s data vVols. Config vVols have the same type of UUID, but it is found in a different way.

Let’s first look at the home directory vVol UUID. This is usually the only one that matters for a given VM.

The vVol UUID of a home directory config vVol can be found under the VM object as well. Once again, you need to access the extension data. Under the VM object, extension data then the config, there is a property called vmStorageObjectId. This shows the home directory config vVol UUID:

Fairly straight forward.

I did say config vVols are a bit trickier and this is somewhat true. Let me explain.

One point I have somewhat glossed over is that a VM can actually have more than one config vVol. This is not super common, but totally possible. A config vVol is really just a small file system (indeed they use VMFS internally)–it is basically a place to put files. With VMFS, or NFS and even vVols, most commonly a VM has a single directory, called the home directory. In VMFS or NFS this is a folder with the VMX file and snapshot directories and swap files etc. In a vVol world, this is a directory which points to its config vVol.

With that being said, sometimes a VM will have a virtual disk on a datastore that is different from where the home directory lies. Therefore there is another folder that is created on the second datastore. So in a vVol world a second config vVol would be created (whether this is on the same array or a different one), which would store the VMDK pointer file for that other data vVol.

First off, how do I know if there is more than one config vVol? Well the simplest way is to run get-datastore on that VM to see if there is more than one vVol datastore associated with that VM.

In this case, I have two vVol datastores associated with this VM. How do I find the UUID for those config vVols? Well one of them is the home, which I can find out like above. But what about the second?

If you detect there is more than one vVol datastore, or you are simply looking for the vVol UUID of a secondary (non-home) config vVol, you can get this from the virtual disk. Unfortunately, I have not seen a way to pull this directly as a property–it seems you must parse the string to get it.

In a given virtual disk (by using get-harddisk) you can access a property in the extension data under backing then file name:

The string under that property starts with the datastore name in square brackets, then a space, then the config vVol UUID then the name of the VMDK. If you split from the last bracket then the slash, and pull the 3rd record you will get that UUID.

Conclusion

So this is how you get the UUIDs of the vVols. In the next post I will talk about how to get them from the Pure Storage FlashArray itself.

PowerCLI and vVols Part II: Finding vVol UUIDs