A Workaround to Identify NFS based Datastore in vSphere
We just had the longest discussion in vSphere Java API forum regarding the “UUID of an NFS datastore.” The question is basically how to find the “UUID” via the vSphere API.
You can create datastores based on either VMFS or NFS. The VMFS can be backed up by local SCSI, or SAN (FC, iSCSI). It’s very easy to find UUID of a VMFS based datastore by calling getUuid() method from the corresponding data object VmfsDatstoreInfo.
Time to learn how to "Google" and manage your VMware and clouds in a fast and secureHTML5 App
For NFS based datastore, it’s a lot complicated. I am glad we digged to the bottom of the issue. Instead of going through the long discussion, I summarize the key takeways from the discussion.
Before jumping into details, let’s clarify one thing: NFS datastore does not have a UUID. (If you want to know more about UUID in vSphere, you should read this blog article.) You can check out the NasDatastoreInfo which does not have uuid property. It does, however, have an identifier like 73ca9790-6dbf88b0, which is not a UUID per se. We will call it simply an ID.
You may be wondering why you should care about the ID. It is pretty important in that it’s used in performance stats like the following:
Counter ID: 329 Counter Instance: 73ca9790-6dbf88b0 Counter Info: datastore.numberWriteAveraged.average Stats value: 2
With this hashed value, you have no idea what datastore it relates to. So you have to find a way to map this ID back to the datastore.
Unlike VmfsDatstoreInfo, NasDatastoreInfo does not have a property uuid. If you connect to ESX directly, you can find the ID is embedded in the url property like: /vmfs/volumes/0d68fdb5-2e73c800. You can of course easily extract the ID there.
But it’s not the case if you go to the vCenter for the same data object. The url there has a value like: netfs://10.3.13.13//export/vmware/. There is no way for you to figure out the ID unless you know the algorithm VMware uses to hash it.
Now, if you try to query performance metrics by queryAvailablePerfMetric(), you will get exception SystemError exception as reported in the discussion.
Fortunately, there is a solution even though not as direct as we like it to be. Here is how you can solve it.
From the HostSystem object of an ESX, grab the “config” property and get its “fileSystemVolume” property, which is typed HostFileSystemVolumeInfo. Check the “volume” property to see if its type is HostNasVolume. If true, then get the “mountInfo” property and get its path which looks like this:
Now you can extrac the ID and build a map from this hashed ID back to the datastore.