• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

virtuallyGhetto

  • About
  • Privacy
  • VMware Cloud
  • Home Lab
  • Nested Virtualization
  • Automation
    • VMware Kickstart
    • VMware API/SDK/CLI
    • VMware vMA/VIMA
    • VMware OVF / OVFTOOL
  • Apple Mac
  • VCSA
  • VSAN
You are here: Home / ESXi / Quick Tip – How to tell if a VMFS datastore is local or not using new vSphere 5.5 API?

Quick Tip – How to tell if a VMFS datastore is local or not using new vSphere 5.5 API?

05/27/2014 by William Lam 3 Comments

I was recently working on a script for a friend that collects some basic information about VMFS based Datastores. While going through the vSphere API 5.5 Reference, I noticed a new property was introduced in vSphere 5.5 API called "local". It looks like we now have a simple way of checking whether a given VMFS Datastore is local or not. In the past, the only semi-reliable method for checking whether a VMFS datastore was local or not was to see if the "multipleHostAccess" property was set to true, which meant it was a shared VMFS. This was not very reliable as it could be a remote VMFS Datastore but only exported to one host so far and the other major caveat is that this property was only available when connecting to a vCenter Server.

To demonstrate this new API property, I have created an example vSphere SDK for Python (pyvmomi) sample called: list_datastore_info.py

Here is a screenshot running the script directly against an ESXi host (you can also connect to vCenter Server as well):

pyvmomi-list-datastore-0
The script also supports a --json|-j output option, here is an example of that:

pyvmomi-list-datastore-1
If you want to be able to format the JSON output in a more friendly manner, you can pipe the string output to python -mjson.tool

pyvmomi-list-datastore-2

More from my site

  • A killer custom Apple Mac Mini setup running VSAN
  • Does VSAN work with Free ESXi?
  • ESXi 5.5 Kickstart script for setting up VSAN
  • Does reinstalling ESXi with an existing VSAN Datastore wipe your data?
  • Quick Tip – Steps to shutdown/startup VSAN Cluster w/vCenter running on VSAN Datastore
Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: ESXi, vSphere 5.5 Tagged With: datastore, esxi 5.5, local datastore, vmfs, vSphere 5.5

Reader Interactions

Comments

  1. Jorge says

    11/26/2014 at 12:56 am

    Awesome post! I have a question… I see you can get the total capacity for each datastore. Is there any way of getting the used/free disk space for each datastore?

    Thanks!

    Reply
  2. beltwaybenny says

    01/25/2015 at 1:54 pm

    I upgraded my lab to 5.5 U2 today to support vaai unmap with powershell get-esxcli, was going to use the ‘local’ property to check to see if the datastore was on the SAN:

    I was surprised to see that the default local VMFS datastore (the one on the internal RAID-1 OS disks) is showing local = false (incorrect) while showing MultipleHostAccess = False (correct):

    PS C:\> $datastores[0].ExtensionData.info.vmfs.local
    False
    PS C:\> $datastores[0].ExtensionData.Summary.MultipleHostAccess
    False

    Ben

    Reply
    • William Lam says

      01/26/2015 at 3:04 pm

      I’ve seen internal RAID devices show miss-reporting as ESXi can’t tell if the device is in fact remote or local, if I were to guess the device is most likely connected via SAS Controller? This is challenge for some devices that are truly local and the only way to get them to be recognized as a local device is by adding an ESXCLI claimrule.

      Reply

Thanks for the comment! Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Services Business Unit (CSBU) at VMware. He focuses on Automation, Integration and Operation for the VMware Cloud Software Defined Datacenters (SDDC)

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Sponsors

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy