WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

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

Categories // ESXi, vSphere 5.5 Tags // datastore, ESXi 5.5, local datastore, vmfs, vSphere 5.5

Removing Previous Local Datastore Label for Reinstall in ESXi 5

04.24.2012 by William Lam // 18 Comments

If you reinstall ESXi 5 on system that had a previous copy, one thing you might have noticed is the local VMFS datastore label is preserved. This is also true if you perform an unattended installation using kickstart and specifying the overwritevmfs parameter, a new VMFS volume is created but it still uses the old label. This can cause some issues for scripted installs where you decide to rename the local datastore from the expected default "datastore1" label.

UPDATE (12/21) - This issue has been resolved in the latest release of ESXi 5.0 Update 2, you can refer to the release notes for more details on other updates and fixes.

Though it is actually pretty easy to get around this problem by deleting the VMFS partition prior to starting the new ESXi installation. Below are three methods depending on the installation option you have chosen. Please be absolutely sure about the VMFS volume prior to deleting the partition.

Method 1 - While you still have login access to previous ESXi install

If you still have access to the system before the re-install, you can delete the VMFS partition before rebooting and starting the installation (ISO or kickstart). You will first need to identify the device that is backing your local datastore, you can use the following ESXCLI command which will provide a mapping of your datastore to device.

You will need to make a note of the "Device Name" which can be a naa.* or mpx.* depending on how your ESXi host identifies the disk. You should also make a note of the partition number for the VMFS volume which we will also confirm in the next step. Using the partedUtil we can check the partitions found on the disk and we can confirm that partition 3 is being used for VMFS. Using the "getptbl" option and specifying the full path to the disk which is under /vmfs/devices/disks/naa.* we can retrieve the partition info as shown below.

Now we just need to delete this partition which will wipe the VMFS headers which includes the datastore label. We can do this by using partedUtil and using the "delete" option which will require the full path to the disk in our previous step.

You can now reinstall ESXi and it will use "datastore1" as it's default VMFS label.

Note: The disk that contains the local ESXi 5 install will always have VMFS as the 3rd partition, where as other VMFS volumes will only have a single partition.

Method 2 - During manual installation using ESXi 5 ISO

When you boot up the ISO, you are brought to the "Welcome to VMware ESXi 5.0.0 Installation" page, you will need to login to ESXi Shell by pressing ALT+F1. The username will be root and there is no password, just hit enter. Just like in Method 1, you will need to identify the device for your local datastore but instead of using esxcli, you will need to use localcli as hostd is currently not running.

Here is a screenshot of the identifying the local datatstore device and deleting the VMFS partition:

You can now jump back to the installer by pressing ALT+F2 and continuing with the reinstall and it will use "datastore1" as it's default VMFS label.

Method 3 - Kickstart Installation

If you wish to ensure that the default "datastore1" label is always available for scripted installs, you can using the following snippet in your %pre section of your kickstart. This will search for all disks under /vmfs/devices/disks andĀ  find the deivce that is backing a local ESXi installation and delete it's VMFS partition prior to starting the installation.

for DISK in $(ls /vmfs/devices/disks | grep -v vml);
do
        DISK_PATH=/vmfs/devices/disks/${DISK}
        VMFS_PARTITION_ID=$(partedUtil getptbl ${DISK_PATH} | grep vmfs | awk '{print $1}')
        if [[ ! -z ${VMFS_PARTITION_ID} ]] && [[ ${VMFS_PARTITION_ID} -eq 3 ]]; then
                partedUtil delete ${DISK_PATH} 3
        fi
done

Note: To be extra cautious, you should also consider disabling any additional remote LUNs that can be seen during the installation using the trick found here.

Categories // Uncategorized Tags // datastore label, local datastore, partedUtil

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download TokenĀ  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

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

Copyright WilliamLam.com © 2025

 

Loading Comments...