In Part 6, we will take a look at how we can use the new VAMI APIs to easily associate the underlying VMDKs to their respective OS disk partitions for a VCSA or PSC node. In addition, the workflow of increasing the disk capacity for a specific partition has also been simplified further with the new VAMI APIs. After increasing the specific VMDK size, we can now also trigger the partition resize operation using the VAMI APIs, where as before this used to be a manual task that required SSH access. In vSphere 6.5, there have been a few minor changes to the VCSA's VMDK layout and sizes, for more details, please have a look at this blog post here.
VAMI UI Area of Focus
Unfortunately, there is not a page within the VAMI UI (https://[VCSA]:5480) that either lists or provides the actual mapping of the underlying VMDKs to their respective partition types. You can see the different VMDKs using the vSphere Web/C# Client, but historically the mapping of VMDK to partition type was done manually or you would refer to the table found in the blog post referenced above. Lets see if we can pull this information without needing to go to a UI 🙂
VAMI APIs Used
- GET /appliance/system/storage
- POST /appliance/system/storage/resize
The first function is called Get-VAMIDisks which does exactly as it sounds. It lists all disks (VMDKs) and their associated partition function. You will notice that Disk 1 and Disks 2 does not provide a label (I have already filed a bug internally), but referring to my blog article linked above, we can tell what those map two map to.
An example workflow for increasing the disk capacity, say for example the "DB" partition would first involved the query above. Next, you would then increase the size of the 6th VMDK for your VCSA or PSC node which can be done online while the VM is running using either the vSphere Web/C# Client, PowerCLI or any other vSphere SDK. Finally, to make GuestOS and application aware of the new space increase, you will now run the Start-VAMIDiskResize function which will now make the storage usable. With these two functions, you can see how easy it would be to combine them into a higher level PowerCLI function that performs the workflow we had just described. I will leave this as an exercise for the reader for explore further.
- Exploring new VCSA VAMI API w/PowerCLI: Part 1
- Exploring new VCSA VAMI API w/PowerCLI: Part 2
- Exploring new VCSA VAMI API w/PowerCLI: Part 3
- Exploring new VCSA VAMI API w/PowerCLI: Part 4
- Exploring new VCSA VAMI API w/PowerCLI: Part 5
- Exploring new VCSA VAMI API w/PowerCLI: Part 6
- Exploring new VCSA VAMI API w/PowerCLI: Part 7
- Exploring new VCSA VAMI API w/PowerCLI: Part 8