Demystifying VCF PowerCLI 9.0 SDK

Application Programming Interfaces (APIs) is a way to communicate to a software service programmatically. They define the contract through which external clients interact with underlying services—whether for resource provisioning, lifecycle management, or observability. However, working directly with APIs often requires a deep understanding of request/response models, authentication schemes, and schema-specific nuances.

This is where Software Development Kits (SDKs) come into play. SDKs provide client-side API bindings that abstract raw HTTP requests into language-specific constructs, such as classes and method calls. These bindings are tailored to the programming language in use (e.g., Python, Java, PowerShell), enabling developers to interact with complex APIs using familiar programming constructs. For anyone building tooling or automation, SDKs significantly reduce developer overhead and speed up the development process.

Last week, I published two blog posts outlining our latest advancements in this space:

• Introducing Unified VCF SDK 9.0 for Python and Java
• Introducing VCF PowerCLI 9.0

These posts highlighted how we’ve evolved our SDKs and CLI tools to keep pace with the VMware Cloud Foundation (VCF) API coverage and how developers can get started with it easily.

What is VCF PowerCLI SDK?

PowerCLI is one of the most mature and widely adopted tools for automating VCF, It is a set of PowerShell-based modules built specifically for VMware environments. Over time, PowerCLI has grown to include hundreds of high-level cmdlets, each designed to wrap one or more underlying APIs, providing a consistent and intuitive user experience. These cmdlets follow PowerShell semantics such as Verb-Noun -Parameter value cmdlet syntax, making them ideal for cloud administrators to adopt quickly.

However, as VCF evolves with every major release, its API endpoints undergo significant changes. New APIs are introduced to support new features, while older ones may be deprecated or removed. For example, in VCF 9.0, we introduced dozens of new endpoints, updated several existing ones, and deprecated others—all of which are documented in the VCF 9.0 API Change Log.

Creating handcrafted cmdlets for each of these APIs can take time. The process involves API discovery, design, user experience testing, validation, and documentation, which can cause a delay between the release of a new VCF version and the availability of corresponding high-level PowerCLI cmdlets.

To bridge this gap, we introduced the VCF PowerCLI SDK—a set of auto-generated PowerShell modules that provide 1:1 bindings with the VCF REST APIs based on the OpenAPI specification. These modules expose lower-level commands like Invoke-* and Initialize-*, ensuring full API coverage from day zero of a VCF release. While these cmdlets may not be as user-friendly as high-level cmdlets, they offer unmatched flexibility and early access to new capabilities introduced in VCF.

In this post, I’ll walk you through:

• How to use the PowerCLI SDK
• How auto-generated cmdlets differ from high-level cmdlets

Let’s dive into exploring the VCF PowerCLI SDK and how auto-generated cmdlets are mapped to their corresponding API bindings.

Exploring VCF APIs

As you may know, VMware Cloud Foundation (VCF) is an integrated software platform that combines VMware’s compute, storage, networking, and automation technologies into a single unified offering. It provides a complete stack for deploying and managing private cloud environments. Each component in VCF offers its own set of APIs. Most components offer REST APIs, and some, such as vSphere and vSAN, provide both REST and SOAP APIs. In this post, we will focus on REST APIs only. You can refer to the API documentation at developer portal.

REST (Representational State Transfer) is an architectural style for building scalable web services over HTTP. A REST API exposes resources (such as VMs, clusters, tasks, or users) via a set of stateless, well-defined operations. These operations use standard HTTP verbs like GET, POST, PUT, PATCH, and DELETE.

For example, let’s consider the following API to create a new virtual machine:

Using Postman as an API client, you can make a request like this. Now, let’s look at how to accomplish the same task using the PowerCLI SDK’s auto-generated cmdlet.

How to use PowerCLI SDK?

The auto-generated cmdlets produced by the PowerCLI SDK have two key verbs: Initialize-* and Invoke-*.

• Initialize: These cmdlets prepare the request body for your API calls. They run on the client side and do not communicate with the vSphere Automation API server.
  
• Invoke: These cmdlets execute the API operation on the server side by taking the request body as an input prepared by Initialize cmdlet.
  

For example, to create a virtual machine, you would use the Invoke-CreateVM cmdlet. However, this API requires an input to create the VM, which can be prepared using the Initialize-VMCreateSpec cmdlet.

How to find corresponding API binding with PowerCLI SDK?

The PowerCLI SDK includes new helper commands to retrieve corresponding cmdlets for each API. These commands are listed below:

Name	PowerCLI SDK Module	Description
Get-NsxOperation	VMware.Sdk.Nsx.Policy	Retrieves cmdlets corresponding to NSX API endpoints.
Get-SrmOperation	VMware.Sdk.Srm	Retrieves cmdlets corresponding to SRM API endpoints.
Get-VcfInstallerOperation	VMware.Sdk.Vcf.Installer	Retrieves cmdlets corresponding to VCF Installer API endpoints.
Get-VcfOpsOperation	VMware.Sdk.Vcf.Ops	Retrieves cmdlets corresponding to VCF Operations API endpoints.
Get-VcfSddcManagerOperation	VMware.Sdk.Vcf.SddcManager	Retrieves cmdlets corresponding to SDDC Manager API endpoints.
Get-vSphereOperation	VMware.Sdk.vSphere	Retrieves cmdlets corresponding to vSphere API endpoints.

If you forget the specific command, you can always run Get-Help Get*Operation.

Example: Finding Cmdlets for Creating a VM

The API path for creating a VM is /api/vcenter/vm with the POST method. To find the corresponding PowerCLI SDK cmdlet, run the following command:

This will list the corresponding cmdlet, Invoke-CreateVM, along with related command information. You can also find the Initialize-VMCreateSpec cmdlet, which is used to prepare the request body.

Here’s an example of how you would create a VM using PowerCLI SDK

1. Define VM Placement Specification

• Purpose: Tells vCenter where to place the new VM.
  
• Parameters:
  
  • Folder: The inventory folder where the VM will be created (group-v4).
    
  • ResourcePool: The compute resource pool assigned to the VM (resgroup-11).
    
  • Datastore: The storage location for the VM’s files (datastore-16).
    
• Output: An object representing VM placement configuration.

 2. Initialize VM Specification

• Purpose: Defines the configuration of the VM you want to create.
  
• Parameters:
  
  • GuestOs: Specifies the operating system type (WINDOWS_SERVER_2025).
    
  • Name: Sets the name of the VM (Webapp-VM).
    
  • Placement: Injects the placement spec created in the previous step.
    
• Output: A full VM creation spec that includes name, guest OS, and placement details.

3. Create the VM

• Purpose: Sends the request to vCenter to create the VM as defined in the previous steps.
  
• Parameter:
  
  • VcenterVMCreateSpec: The complete specification object.
    
• Result: A new virtual machine named Webapp-VM will be created in the specified folder, on the defined resource pool and datastore, with Windows Server 2025 as its OS.

High-Level Cmdlet vs Auto-generated Cmdlet with PowerCLI SDK

The previous example illustrates how to create a new VM using the VCF PowerCLI SDK’s auto-generated cmdlets. However, for this operation, a high-level PowerCLI cmdlet already exists: New-VM.

This is the classic PowerCLI experience: clean, concise, and designed around native PowerShell semantics. High-level cmdlets abstract away the complexity of underlying API calls, offering a well-integrated, user-friendly experience.

The key point is that not all VCF or vSphere API operations are covered by high-level cmdlets, especially when new APIs are introduced in a recent release. That’s where the auto-generated cmdlets from the PowerCLI SDK become essential. These cmdlets are generated directly from the OpenAPI specification and provide immediate, day-zero access to all available REST APIs—even those that don’t yet have curated cmdlet support.

A real-world example is the Global Authorization APIs introduced in VCF 9.0. Currently, no high-level cmdlets are available for managing these APIs. However, with the PowerCLI SDK, you can still consume these endpoints through the corresponding Invoke-* or Initialize-* cmdlets, ensuring you can automate critical operations even if the curated cmdlet isn’t available yet.

Conclusion

PowerCLI offers the best of both worlds—high-level cmdlets for ease of use and auto-generated cmdlets from the VCF PowerCLI SDK for full API coverage. While high-level cmdlets are ideal for common tasks, the SDK-based cmdlets let you access new or advanced VCF features that don’t yet have native support.

To fully automate across the VCF stack—especially after a new release—it’s crucial to understand both types of cmdlets. Use high-level cmdlets when available and fall back to the SDK when you need deeper access. This combined approach ensures you’re always in control, regardless of where the platform evolves.

Resources

Introducing VCF PowerCLI 9.0

Introducing the Hidden Power of the PowerCLI SDK

Rotating Credentials in VCF using PowerCLI SDK

Mastering Get-View: Enhance vCenter User Auditing