Home > vSphere API > A Workaround to Identify NFS based Datastore in vSphere

A Workaround to Identify NFS based Datastore in vSphere

October 4th, 2010 Leave a comment Go to comments

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 secure


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:// 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.

  1. May 12th, 2016 at 04:12 | #1

    Greate post. Keep posting such kind of info on your site. Im
    really impressed by your blog.
    Hey there, You’ve done an incredible job. I’ll certainly digg it and
    in my opinion recommend to my friends. I’m confident they will be benefited
    from this web site.

  2. Ed
    March 23rd, 2017 at 11:34 | #2

    So how would I change an NFS mount from using the FQDN to use the IP but keep the same ID?

  1. May 19th, 2016 at 03:03 | #1