My last post in this series was about getting a VVol UUID and figuring out what volume on a FlashArray it is. But what about the step before that? If I have a guest OS file system how do I even figure out what VMDK it is?
There is a basic option, which can potentially be used, which is correlating the bus ID and the unit ID of the device in the guest and matching it to what VMware displays for the virtual disks.
But that always felt to me as somewhat inexact. What if you accidentally look at the wrong VM object and then do something to a volume you do not mean to? Or the opposite?
Not ideal. Luckily there is a more exact approach. I will focus this particular post on Windows. I will look at Linux in an upcoming one.
- PowerCLI and VVols Part I: Assigning a SPBM Policy
- PowerCLI and VVols Part II: Finding VVol UUIDs
- PowerCLI and VVols Part III: Getting VVol UUIDs from the FlashArray
- PowerCLI and VVols Part IV: Correlating a Windows NTFS to a VMDK
- PowerCLI and VVols Part V: Array Snapshots and VVols
- PowerCLI and VVols Part VI: Running a Test Failover
- PowerCLI and VVols Part VII: Synchronizing a Replication Group
- PowerCLI and VVols Part VIII: Running a Planned Migration
First off, well if this is VVols, wont the volume in Windows just show me my FlashArray (or whatever vendor/model) volume serial number?
No–this is the same idea as with VMFS-based (or NFS, or VSAN-based) virtual disks. VMware virtualizes the VPD information of the volume so you can Storage vMotion it (etc.) between different storage without the guest thinking it sees different storage.
If we look at my Windows VM (which currently has one disk) we will see that the following is its serial number:
NOTE: get-disk only works on Windows 2012 and later, you have to use WMI for earlier versions…
If this field is blank, you likely have the VM advanced setting disk.EnableUUID set to false or unset. This needs to be set to either TRUE.
This setting is the key for this to work. Here is a VMware KB that talks about it:
Is there a down side to setting this? Well I am still looking into it, but the main thing I know is that if this is set on a VM and that VM is running, when it is cloned or Storage vMotioned, the process will not be offloaded via XCOPY to the array. See this blog post here:
So the serial is 6000C29f129e39714f89157a9b73579e.
If I want to do this from the drive letter, it is fairly easy too. So like tell me the drive letter and I will tell you the serial number. This is a combination of get-partition and get-disk.
So the below will return to me the disk that hosts drive E:
get-partition -driveletter E | get-disk
Let’s now look at the virtual disk from a VMware perspective:
Also, 6000C29f129e39714f89157a9b73579e! So perfect, we can make an exact correlation.
So in windows, run get-disk then grab the property SerialNumber and then in vCenter, use get-harddisk against the VM, iterate through the disks and find the one with the matching UUID under extensiondata.backing.uuid.
Fairly simple! And by they way, this process also works for VMFS-based virtual disks too.
I have added a cmdlet in my Pure Storage/VMware PowerShell module that does this for you though.
It takes in a VM, a Drive Letter (C, E, whatever) and returns the resulting matching virtual disk (what you would find by running get-harddisk).
This can be run interactively, or by entering parameters. It also supports pipeline input, so you can pass the VM in via pipline. Some examples:
Returning the resulting disk to another cmdlet. In this case taking the disk and expanding it with set-harddisk. Expands it to 500 GB.
This has been added to my PowerShell module found here.
Note that this will work on any storage platform–not just Pure. It also does not require VVols–it will work with VMFS.
It does have a few requirements:
- The Guest OS must be Windows 2012 or later
- VMware tools must be installed and online
- The Disk.EnableUUID on the VM must be either unset, or set to TRUE.