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):
- Use the ReconfigureComputeResource_Task() and set spec->vsanConfig->enabled to either true or false & spec->vsanConfig->defaultConfig->autoClaimStorage to true
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:
- Use the ReconfigVM_Task() and set spec->vmProfile to the VM Storage Policy ID
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:
- Use the DatastoreNamespaceManager which provides the following two methods
- CreateDirectory()
- DeleteDirectory()
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:
- Use PbmCreate()
Delete VM Storage Policy:
- Use PbmDelete()
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:
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:
- If you wish to evaluate VSAN and its associated APIs, please sign up for the public beta here.
- Sign up for a special VSAN event here
- VM Storage Policy APIs aka Storage Profile APIs will be available in vSphere 5.5
- SPBM (Storage Policy Based Management) MOB in vSphere 5.5
Hi William,
I tried several time to apply the storage policy to vm by calling reconfigVm_task in mob, however, i failed everytime but the task return shows "success", i grabbed the uuid of the policy i set and construct the mob body like
1bb9e360-d568-457d-8141-4707278a6463 => ( uuid of the policy i got from spbm )
any idea?
it hides the tags
''
'third-change'
''
'1bb9e360-d568-457d-8141-4707278a6463'
''
''
''
last time
spec
vmProfile
profileId 1bb9e360-d568-457d-8141-4707278a6463 /profileId
/vmProfile
/spec
vmProfile is an array and its of type VirtualMachineDefinedProfileSpec so it looks like your request is not correct. Also note, this will only change the VM Home but not the underlying disks. I will have an example in the coming days on how to change VM Storage Policy, stay tuned
Thanks for replying!
I checked out VirtualMachineDefinedProfileSpec
public class VirtualMachineDefinedProfileSpec
extends VirtualMachineProfileSpec
{
@XmlElement(required = true)
protected String profileId;
protected VirtualMachineProfileRawData profileData;
...
I've specified the profileId, and in this file: bora/vim/vmodl/vim/vm/DefinedProfileSpec.java
i found the profileData is optional, so I can't figure out why I've messed up the request, could you point that out?
thanks!
i've figured it out, it should be looks like:
\
\
\1bb9e360-d568-457d-8141-4707278a6463\
\
\
Glad to hear you got it working. I will also be posting some sample code relating to this topic next week.
Do you know a way for a vCenter server to be replaced with a new vCenter build in an existing VSAN cluster? I get UUID mismatch anytime I try and add preexisting VSAN hosts contributing storage to the new vCenter. I was told by VMware I'dbe able to jjust disconnect hosts and add them to new vCenter VSAN cluster but I still get UUID mismatch errors. Thoughts?
I assume your workflow is create a new VSAN Cluster in the new VC, disconnect all hosts in the old VC and then add one host at a time to the new VC? That should work as I've done this before as well. If you try to add all them, then you'll see the error but if you add one at a time, it works
Hi William,
I am using ReconfigureComputeResource_Task() for enabling the vsan traffic for the vmkernel interface. I am able to set the host system and the vmkernel interface, if we execute this task it's returning as success but if we see in vSphere it's still showing as disabled for the particular vnic.
PFB code.
ClusterConfigSpecEx clusterConfigSpecEx = new ClusterConfigSpecEx();
VsanHostConfigInfo[] hostSpecarr=new VsanHostConfigInfo[1];
VsanHostConfigInfo hostSpec=new VsanHostConfigInfo();
hostSpec.setHostSystem(host.getMOR());
VsanHostConfigInfoNetworkInfoPortConfig pConfig=new VsanHostConfigInfoNetworkInfoPortConfig();
pConfig.setDevice(device);
List configList=new ArrayList();
configList.add(pConfig);
hostSpec.setEnabled(true);
VsanHostConfigInfoNetworkInfoPortConfig[] vsanHostConfigSpec=configList.toArray(new VsanHostConfigInfoNetworkInfoPortConfig[configList.size()]);
VsanHostConfigInfoNetworkInfo vnetifo = new VsanHostConfigInfoNetworkInfo();
vnetifo.setPort(vsanHostConfigSpec);
hostSpec.setNetworkInfo(vnetifo);
hostSpecarr[0]=hostSpec;
clusterConfigSpecEx.setVsanHostConfigSpec(hostSpecarr);
Task task=ccr.reconfigureComputeResource_Task(clusterConfigSpecEx, true);
Please help me on this.
There's actually a better way to update the VMK if it already exists.
There's a task called UpdateVsan_Task located in host->configManager->vsanSystem.
The only thing needed is a bit of port info associated with the device name (i.e. vmk0 or vmk1 or vmk2), and then execution of the task. After that, reconfiguring the compute resource should not be needed.
I'm doing this via pyVmomi / VConnector and Ansible.
Works just fine. We have our Auto Deploy set to statefully install the host outside of the VSAN enabled cluster, and then Ansible puts the host into maintenance mode, applies the change, and moves it to the cluster.
From there, the cluster assumes auto claim and such items.
No fuss.