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.

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 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:// 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.

This entry was posted in vSphere API and tagged , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

One Comment

  1. Posted May 12, 2016 at 4:12 am | Permalink

    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.

One Trackback

  • […] Ce chemin n’était pas correct car dans notre cas l’ID du volume VMFS était celui du site source. Oui, vous avez bien lu, l’ID et non l’UUID, car les montage NFS n’en n’ont pas et sont simplement hashé. ici un très bon article sur le sujet : A Workaround to Identify NFS based Datastore in vSphere. […]

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.