WilliamLam.com

Why you should rename the default VSAN Datastore name

by // 10 Comments

Something that I have noticed early on when working with VSAN is that the VSAN datastore name is automatically selected for you and will always default to vsanDatastore. This is not a bad thing as it simplifies the setup of VSAN which is already dead simple. To enable VSAN, it is simply checking a box in the configuration of your vSphere Cluster just like you would when enabling vSphere DRS or HA.

From an operational standpoint, I think this can be a potential issue. What happens when you have a multiple VSAN Clusters under the same vSphere Datacenter object or even across different vSphere Datacenter objects? I recently came across this while re-building one of my lab environments, can you spot the problem in the screenshot below?

Here we have two VSAN Datastores within the same vSphere Datacenter. Datastore names under a single vSphere Datacenter must be unique. I am sure some of you may have already experienced this with local datastore names using the default "datastore1". vSphere will automatically append "(n)" to the name where n is the number of instances seen in the environment.

In this next example, we have two VSAN Datastores but they are split across two vSphere Datacenters. Since unique name is enforced at the Dataenter boundary, it is even worse now because you have the same name used across both VSAN Clusters.

Even though a user will most likely drill down into a specific environment when provisioning a Virtual Machine, I think it is critical to have a good naming scheme for your infrastructure. What happens when you have someone run an audit of all your VMs and all they showed for their datastore name was "vsanDatastore" and you had multiple VSAN Clusters? Would it not be more useful to have a bit more details in the datastore name to help map it back to some logical/physical container that is a bit more meaningful? I personally would think so and would help in times of troubleshooting where time is of the essence. 

Luckily this can easily be remediated since a VSAN Datastore operates just like any other datastore in which you can rename it. VSAN itself does not use the name to uniquely identify the datastore, it implements a unique UUID for each of the VSAN datastores. Simply renaming the VSAN Datastore to something more appropriate such as including the name of the vSphere Cluster will come a long when you need to correlate a Virtual Machine back to a particular compute/storage resource. 

I wonder if it would be a useful to have a feature in VSAN to automatically append the vSphere Cluster name to the default VSAN Datastore name? What do you think? 

vdq - A useful little VSAN utility

by // 9 Comments

While re-building a couple of my Nested ESXi VMs for VSAN using some newer builds, I came across a nifty little VSAN utility called vdq which I assume stands for either VMware Disk Query or VSAN Disk Query. I actually found this utility by accident while poking around in the ESXi Shell as I was looking for a quick way to inspect the disks and I know there are a couple other methods which are officially supported by VMware such as RVC or ESXCLI.

Disclaimer: This is not officially supported by VMware, please use at your own risk. 

vdq provides two useful commands, one that queries the disks on your ESXi host and show whether they are eligible or not for VSAN. The other is the disk mappings once VSAN has been configured and enabled on your ESXi host.

To query the disks on your ESXi host, you can run the following command: vdq -q

You will be presented with a lot of useful information such as the disk device name, VSAN node UUID, the state of the disk (whether or not it can be used by VSAN or if it is already in use), reason which includes more details, whether the disk is an SSD or HDD and also if the device is in a PDL (Permanent Device Loss) state.

You can also specify the -H option which makes the output a bit more readable as the default output is using Python. In this next screenshot, if we enable VSAN through the vSphere Web Client we now see that the VSANUUID property is now populated and the state of the disks have now changed.

The next command that is also handy once VSAN is enabled is to quickly get the VSAN disk group mapping by running the following command: vdq -i

With this command you can quickly find out the SSD that is front-ending the set of HDD for a given disk group. This command came in handy while re-building my ESXi hosts as I wanted to blow away the existing VSAN configuration. To do so, you would need to use ESXCLI and by leveraging vdq, I was able to quickly get the disk mappings and more importantly a command I could easily remember.

In general, I would still recommend using either ESXCLI or RVC which is already pretty simple to use but thought I share this little tip if you ever need to just quickly inspect an ESXi host for VSAN.

VMware VSAN APIs

by // 15 Comments

For customers who are currently evaluating VMware VSAN, the vSphere Web Client is the primary interface for managing and configuring VSAN. However, these exact same VSAN operations can also be accessed programmatically from an Automation perspective. Given that I had spent quite a bit of time playing with VSAN in the lab and exploring some of its APIs, I thought it might be useful to share some of the common VSAN operations mapped to their respective APIs.

There are two main categories of operations that you should be aware of when working with VSAN:

  • VSAN specific operations
  • VM Storage Policy operations

VSAN Operations

The VSAN specific operations are available as part of the vSphere 5.5 API and the list below are the supported operations:

Enable/Disable VSAN on a vSphere Cluster (automatic claiming):

Manual Disk Claiming for an ESXi host:

  • Each ESXi host provides a vsanSystem manager at configManager->vsanSystem which provides the following methods for disk management
    • AddDisks_Task()
    • InitializeDisks_Task()
    • QueryDisksForVsan()
    • QueryHostStatus()
    • RemoveDisk_Task()
    • RemoveDiskMapping_Task()
    • UpdateVsan_Task()

Enable VSAN traffic type for a VMkernel interface

  • Use the ReconfigureComputeResource_Task() and set spec->vsanHostConfigSpec->HostSystem to the ESXi host you wish to configure and  spec->vsanHostConfigSpec->networkInfo->port->device to the specific VMkernel interface you wish to enable VSAN traffic type on

Internal VSAN manager for accessing low level CMMDS (Clustering Monitoring, Membership and Directory Services), object & disk management APIs:

  • Each ESXi host provides a vsanInternalSystem manager at configManager->vsanInternalSystem which provides the following methods for working with the lower level system of VSAN
    • QueryCmmds()
    • QueryObjectsOnPhysicalVsanDisk()
    • QueryPhysicalVsanDisks()
    • QueryVsanObjects()

Change the VM Storage Policy for a Virtual Machine Home OR Virtual Machine Home and Virtual Disk:

Change the VM Storage Policy for Virtual Machine Virtual Disk:

  • Use the ReconfigVM_Task() and set spec->deviceChange->device to the specif Virtual Disk to be reconfigured and set  spec->deviceChange->vmProfile to the VM Storage Policy ID

Enter Maintenance Mode for an ESXi host in a VSAN Cluster:

  • Use the EnterMaintenanceMode_Task() and set spec->
    maintenanceSpec->vsanMode->objectAction to the specific data accessibility mode defined here

Create and Delete directories on a VSAN Datastore:

SPBM

For VM Storage Policies, VSAN leverages the SPBM (Storage Policy Based Management) framework which allows administrators to create policies that define specific storage capabilities such as performance and reliability that can then be applied to a Virtual Machine. The SPBM API is exposed as a separate API endpoint in vCenter Server and will be required if you wish to create additional VM Storage Policy leveraging VSAN storage capabilities.

Query list of available VM Storage Profiles defined:

Create VM Storage Policy:

Delete VM Storage Policy:

Check VM Storage Policy Compliance:

Given a Virtual Machine Home or Virtual Disk, provide associated VM Storage Profile:

Given a VM Storage Profile, provide the associated Virtual Machine Home or Virtual Disk:

PbmQueryAssociatedEntity
PbmQueryAssociatedProfiles

Hopefully this provides a good overview of some of the common VSAN / SPBM operations and their associated API methods. If I have some spare cycles, I may create some sample scripts leveraging some of these API methods. In the meantime, you can check out these RVC (vSphere SDK for Ruby) modules leveraging both VSAN and SPBM APIs here and here.

Additional Resources: