What is the best practice way of automating vSphere?

[Ruin9]

I have used PowerCLI to some extent. It really seems like a powerful tool for automating the vSphere infrastructure.

Along with the usual PowerCLI commandlets, it seems that some advanced users are also using Get-View to unlock more automation possibilities. I have not used this yet.

From what I have seen there is also a REST(ful) API for vSphere, however, I am not sure where to find the full documentation of it.

Maybe there are also other possibilities for automating some tasks in regards to vSphere.

From personal experience, PowerCLI without Get-View seems to lack functionality in some fields and seems to not work when trying to perform certain tasks that I can do through the GUI.

Some examples that I remember include:

(Some of these may have been fixed, I haven't done tests lately)

• Move-Template doesn't seem to move templates to a specific folder
• Remove-NetworkAdapter -NetworkAdapter $my_adapter -Confirm:$false doesn't allow me to remove network adapters from powered on VMs. This is possible through the GUI.
• Changing Reservations/Limits/Shares for CPU, RAM and HDD was not very consistent and was buggy from my tests.

What I want to know is:

Which automation choice provides the most capabilities and features so that I can go this way and not worry that I will be limited in some way.

I feel that anything that is possible through the GUI should be possible through other automation means.

vSphere version: 6.5

PowerCLI version: VMware PowerCLI 6.5 Release 1

[LucD · Accepted solution]

Personally I think that VMware PowerCLI is the best automation tool, provided PowerShell is your thing.

The PowerCLI cmdlets cover a substantial area of what is available in vSphere.

What is covered by the cmdlets, and what data is returned in the object properties is a subset of all that is available.

Although there is no hard number published, I feel that the cmdlets and the properties cover 70%-80% of what an administrator would need in his daily vSphere related tasks.

The remaining 20%-30% can be reached via the SOAP API methods and the objects they return (see API Reference).

These SOAP API require the use of the Get-View cmdlet and/or the use of the ExtensionData property.

Note that besides these public API, there are a number of private/hidden API, which means that not everything available through the client might be available through a public API.

Since a couple of years VMware is migrating from SOAP to REST.

This migration is still ongoing, and at that moment both are available.

The REST API can be explored via your vSphere Server (see for example Understanding the VMware REST API interface)

There are 2 ways to access these REST API, via Invoke-RestMethod or via the services available when you connect (see Exploring new VCSA VAMI API w/PowerCLI: Part 1)

So in conclusion: yes, PowerCLI is a perfetc choice. You might need to use the SOAP and/or REST API for specific actions.

What is behind a private API is of course not available.

[Ruin9]

Thank you for your detailed response.

I will definitely take a look at the API references.

I should also do some tests with the newer PowerCLI versions. Maybe they have fewer bugs.