PowerCLI has long established itself as a trusted and widely adopted automation tool across VMware environments. It remains one of the most preferred tools among our customers, and its popularity is reflected in the numbers—we estimate over 1.5 to 2 million downloads each year. For those curious, these figures can be verified by looking at some states on the PowerShell Gallery.
What makes PowerCLI so effective comes down to two key strengths. First, it’s built on PowerShell, offering both a command-line interface and access to the full range of high level programming language constructs. This allows users to not only execute commands interactively but also build custom automation scripts and workflows suited to their automation requirements. Second, PowerCLI abstracts underlying APIs into a consistent and intuitive set of commands(aka cmdlets)that follows Verb-Noun syntax, thus making automation more accessible and easier to integrate across the clouds.
Over the years, PowerCLI has earned the trust of the community, and we continue to remain invested in delivering improvements going forward. With that, we’re pleased to announce the general availability of VCF PowerCLI 9.0, formerly known as VMware PowerCLI.
This change in name—from VMware PowerCLI to VCF PowerCLI—is done to keep compliant with VCF versioning and release cycles. Having said that, it is important to note that releasing VCF PowerCLI 9.0 is more than just a rebranding exercise.
Whats New with VCF PowerCLI 9.0
In this release we are introducing brand new capabilities across the VCF stack, performance enhancements, improved API bindings with better usability. It wont be possible for me to outline each and every aspect of the release but I would detail out some of the most important enhancements we have delivered with VCF PowerCLI 9.0. Please refer to VCF 9.0 release notes for more information.
Highlights
- Performance
- New Module for NSX Virtual Private Cloud
- New Module for SDDC Manager
- Usability improvements with PowerCLI SDK
- Global Authorization APIs and PowerCLI bindings
- Bug fixes
Let us take a look at each of these improvements in detail.
Performance
As mentioned earlier, the release of VCF PowerCLI 9.0 is more than just a rebranding effort—it provided us the opportunity to introduce new capabilities while also revisiting and optimizing some of the core components of the PowerCLI module, with performance being a major focus.
To understand the performance improvements, it’s important to understand that PowerCLI cmdlets are developed using two primary approaches: PowerShell script-based functions and .NET-based compiled classes.
Script-based cmdlets, written as advanced functions, offer development flexibility but rely on the PowerShell engine for runtime interpretation, which can introduce performance overhead—especially in data-intensive or repetitive scenarios.
In contrast, compiled cmdlets are implemented as statically typed .NET classes. These are precompiled and run directly within the .NET runtime, benefiting from Just-In-Time (JIT) compilation, optimized memory usage, and more efficient pipeline execution.
With VCF PowerCLI 9.0, some of the core cmdlets have been rewritten as .NET-based compiled classes. This shift significantly reduces execution overhead and improves performance across the board, in some scenarios up to 70%. One of the most noticeable gains you can immediately observe is in module import time. On my Windows Server 2025 the old VMware.PowerCLI module import time took more than 1 minute. VCF.PowerCLI import operation concluded within 18 seconds and this is significantly better compared to older versions of PowerCLI.
Another aspect that helped in improving the performance is re-packaging cmdlets to fewer sub modules. Each powershell module is either a .psm1, psd, or a .dll file. Fewer submodules reduce the number of modules required to load in memory, reducing the inter dependency between the sub modules and improving the overall I/O performance. Below the screenshot of the import operation. Please note that the time taken to import may vary system to system.
Virtual Private Cloud
VCF PowerCLI 9.0 introduces a new module to extend VPC capabilities via PowerCLI, These extended functionalities are now accessible through both the vSphere UI and VCF PowerCLI 9.0.
Virtual Private Clouds (VPCs) are logically isolated networking subnets routed together by a VPC Gateway. VPCs are defined under their NSX Project by either an Enterprise Admin or a Project Admin.
A VPC can have the following types of subnets:
- Private – VPC: A subnet scoped to the VPC and routed with other subnets inside the same VPC, but not to the outside network. NAT is needed if outside communication is required.
- Private – Transit Gateway (Recommended): Subnets allowing inter-VPC connectivity below the Transit Gateway without NAT. It requires IP translation if workloads need to be reachable to an outside network.
- Public: A subnet that is accessible from outside the environment, from other VPCs but also from customers and workload above the Transit Gateway.
Let us understand this one from an example, I have an application called holodeck. This application requires 3 networks, Web, DB, and App. To provision the holodeck application we would create a VPC and these 3 subnets using PowerCLI. The high-level workflow would like this –
Upon successful execution of below script you should have a VPC for your application with all the required subnets and it will reconfigure the application VMs network adapter to be assigned to VPC Subnets.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
$subnetRequired = @('Web','App','DB') #required subnets for application New-Vpc -Name "Holodeck-Vpc" -PrivateIp "192.168.0.0/24" -Description "PowerCLI 9.0 Demo, VPC!" #create a new VPC $vpc = Get-Vpc -Name "Holodeck-Vpc" #retrieve newly created VPC foreach($subnet in $subnetRequired) { #provision application networks New-VpcSubnet -Vpc $vpc -Name $subnet -AccessMode Private -DhcpMode Server } Get-VM -name 'HoloDeck-vpc-App' |Get-NetworkAdapter |Set-NetworkAdapter -Subnet 'App' -Confirm:$false #Assign App Subnet to Holodeck-vcp-App VM Get-VM -name 'HoloDeck-vpc-Web' |Get-NetworkAdapter |Set-NetworkAdapter -Subnet 'Web' -Confirm:$false #Assign Web Subnet to Holodeck-vcp-App VM Get-VM -name 'HoloDeck-vpc-DB' |Get-NetworkAdapter |Set-NetworkAdapter -Subnet 'DB' -Confirm:$false #Assign DB Subnet to Holodeck-vcp-App VM |
In conclusion, you’ve seen how effortlessly we created VPCs and their subnets. Furthermore, the Virtual Machine Network Adapter cmdlets have been updated to integrate with VPC objects, thus allowing you to configure VCP subnets as VM networks using VCF PowerCLI.
SDDC Manager
A new module introduced to provide SDDC management functionalities. To use the below cmdlets, first connect SDDC Manager using Connect-VcfSddcManager cmdlet.
Connect SDDC Manager
Connect-VcfSddcManager -Server sddcmanager-a.site-a.vcf.lab -User ‘administrator@vsphere.local’
Get-SddcCluster
Retrieves information about one or more Cluster objects from SDDC Manager Server.
Get-SddcDomain
Retrieves information about one or more Domain objects from SDDC Manager Server.
Get-SddcHost
Retrieves information about one or more Host objects from SDDC Manager Server.
Get-SddcVcenter
Retrieves information about one or more vCenter objects from SDDC Manager Server.
Apart from these 4 cmdlets we also offer a full set of SDDC manager API bindings with VMware.Sdk.Vcf.SddcManager module offered by PowerCLI SDK. These API bindings are the quickest way to offer feature parity with SDDC Manager APIs in PowerCLI. We will discuss the PowerCLI API bindings in a later section of this blog post.
PowerCLI SDK
Ever wondered how PowerCLI manages to offer near-immediate support for the latest VMware Cloud Foundation (VCF) features right after a new version is released? The answer lies in the auto-generated API bindings offered by PowerCLI SDK.
PowerCLI is essentially a CLI client that communicates with backend APIs, similar to vSphere Client or any management client offered in VCF. What sets it apart is the way it abstracts these APIs into user-friendly PowerShell cmdlets, handcrafted by our engineering team to deliver a smooth CLI experience. But here’s the challenge: building these high-level cmdlets takes time. Each one is thoughtfully designed and tested to align with PowerShell best practices. That means, when new VCF features ship, there can be a gap before the corresponding high-level cmdlets are available.
To bridge that gap, we rely on auto-generated API bindings built from OpenAPI specifications. This isn’t entirely new—we’ve followed a similar approach in the past with SOAP APIs, where we offered Get-View and ExtensionData capabilities for deeper access.
With our modern REST APIs, the same principle applies. We now publish auto-generated PowerCLI SDKs based on OpenAPI specifications, which immediately expose all available API endpoints as PowerShell cmdlets. While these auto-generated cmdlets may not be as intuitive as high-level ones like Get-VM or New-VM, they give you full API access on Day 0 of a new release.
Here’s the approach we take:
- Enable full API access instantly through auto-generated cmdlets.
- Identify top use cases, then gradually release polished, high-level cmdlets around them.
A great example of this in action is VPC (Virtual Private Cloud). When VPC support was introduced in VCF 5.2, PowerCLI shipped with API bindings out of the box—so users could automate VPC tasks immediately. Now, with our latest release, we’ve added high-level cmdlets that make working with VPCs even simpler and more PowerShell-native.
This hybrid approach ensures you never have to wait to automate new features—and you still get the elegance and ease-of-use that PowerCLI is known for.
As outlined earlier, the auto-generated cmdlets are less intuitive compared to a high-level cmdlet. In VCF PowerCLI 9.0 we revamped these cmdlets to improve the usability experience and I would dive deeper into some of these improvements.
Syntax behind PowerCLI SDK cmdlets
Unlike high-level cmdlets like Get-VM or New-VM, the auto-generated cmdlets do not follow Verb-Noun syntax. Rather the cmdlets only have 2 verbs-
Initialize – cmdlets to prepare the data structures, if any, for your API calls. These cmdlets function on the client side and do not communicate with the vSphere Automation API server.
Invoke- cmdlets to execute the operations on the server side.
For example, let us create a tag using auto generated bindings.
What’s improved with PowerCLI SDK?
The common challenge that we identified is that we are generating the bindings automatically but the question remains how to find the correct PowerCLI SDK cmdlet for a corresponding API operation? I am happy to inform you that with VCF PowerCLI 9.0 we have improved on this aspect greatly by introducing new helper cmdlets for PowerCLI SDK.
Better query with PowerCLI SDK cmdlets
We have introduced a new set of cmdlets which assists in finding the relevant cmdlet form PowerCLI SDK. These cmdlets are –
| Name | PowerCLI SDK Module | Description |
| Get-NsxOperation | VMware.Sdk.Nsx.Policy | This cmdlet retrieves the PowerCLI SDK cmdlets that correspond to one or more NSX API endpoints. |
| Get-SrmOperation | VMware.Sdk.Srm | This cmdlet retrieves the PowerCLI SDK cmdlets that correspond to one or more SRM API endpoints. |
| Get-VcfInstallerOperation | VMware.Sdk.Vcf.Installer | This cmdlet retrieves the PowerCLI SDK cmdlets that correspond to one or more VCF Installer API endpoints. |
| Get-VcfOpsOperation | VMware.Sdk.Vcf.Ops | This cmdlet retrieves the PowerCLI SDK cmdlets that correspond to one or more VCF Operations API endpoints. |
| Get-VcfSddcManagerOperation | VMware.Sdk.Vcf.SddcManager | This cmdlet retrieves the PowerCLI SDK cmdlets that correspond to one or more SDDC manager API endpoints. |
| Get-vSphereOperation | VMware.Sdk.vSphere | This cmdlet retrieves the PowerCLI SDK cmdlets that correspond to one or more vSphere API endpoints. |
How to use PowerCLI SDK?
Let us consider the same example as explained earlier. The API path for all the APIs related to Tag Category is api/cis/tagging/category, You can find this either by developer center in vSphere UI or by referring to the developer portal.
Step 1 Use Get-vSphereOperation to find the corresponding PowerCLI binding
|
1 |
Get-vSphereOperation -Path api/cis/tagging/category |
The PowerCLI SDK offers two cmdlets that align with the tag category. You can refine the output using the Method parameter. Use the GET method to list tag categories and the POST method to create them. For more details on each cmdlet, refer to Get-Help.
Step 2 Create a tag category
|
1 2 3 4 |
$TaggingCategoryCreateSpec = Initialize-TaggingCategoryCreateSpec -Name "Holodeck" -Description "A tag category for custom folders" -Cardinality "SINGLE" -AssociableTypes "Folder" $tagCategoryID = Invoke-CreateCategory -TaggingCategoryCreateSpec $TaggingCategoryCreateSpec |
Step 3 Create a tag in that category
You use the tag category ID from the previous step.
|
1 2 3 |
$TaggingTagCreateSpec = Initialize-TaggingTagCreateSpec -Name "Holodeck-App" -Description "example of a tag from PowerCLI" -CategoryId $tagCategoryID $tagID = Invoke-CreateTag -TaggingTagCreateSpec $TaggingTagCreateSpec |
This was just a simple example of using PowerCLI SDK to create a tag. Our recommendation is to continue using High-level cmdlets if they are available for the respective task. Use PowerCLI SDK only if the high level cmdlets are not available.
Global Authorization APIs
In vSphere, authorization determines what actions an authenticated user is allowed to perform. After a user authenticates (proves their identity), vSphere uses Roles, Privileges, and Permissions to authorize access to objects and operations.
Privilege
A privilege is the most granular level of access control in vSphere. It defines specific actions a user can perform, such as “Power On VM” or “Modify Datastore.”
Example:
Virtual machine > Interaction > Power On
Datastore > Allocate space
A role is a collection of privileges. It represents a set of capabilities required for a user or group to perform certain tasks.
Example:
Read-Only Role: Includes only privileges to view objects.
Administrator Role: Includes all available privileges.
Custom Role: Administrator can select set of privileges and map it to a custom role
A permission ties a user or group to a role on a specific object in the vSphere inventory.
Example:
Grant the “Power User” role to user jatin on VM-Production01.
For a long time customers have asked us to provide API functionalities to manage privileges, roles, and permissions, that is authorization operations in vSphere. In the past we did not have these sets of APIs and because of that these operations were manual and led to inconsistencies in how they manage authorization across multiple vSphere environments. I am happy to announce that the new set of APIs are now available with VCF 9.0 and their API bindings are also made available via PowerCLI SDK.
| Component | PowerCLI SDK cmdlet | Description |
| Privileges | Invoke-VcenterAuthorizationPrivilegesGet | Returns the detailed information about a specific authorization privilege in the vCenter Server |
| Invoke-VcenterAuthorizationPrivilegesList | Queries the authorization privileges in the vCenter Server matching given criteria | |
| Roles | Invoke-VcenterAuthorizationRolesCreate | Creates a new authorization role in vCenter Server |
| Invoke-VcenterAuthorizationRolesDelete | Deletes an authorization role from the vCenter Server. | |
| Invoke-VcenterAuthorizationRolesUpdate | Updates an existing authorization role in the vCenter Server. | |
| Invoke-VcenterAuthorizationRolesGet | Returns the detailed information about a specific authorization role in the vCenter Server. | |
| Invoke-VcenterAuthorizationRolesList | Queries the authorization roles in the vCenter Server matching given criteria. | |
| Permission | Invoke-VcenterAuthorizationPermissionsCreate | Creates a new authorization permission in vCenter Server. |
| Invoke-VcenterAuthorizationPermissionsDelete | Deletes an authorization permission from the vCenter Server. | |
| Invoke-VcenterAuthorizationPermissionsUpdate | Updates an existing authorization permission in the vCenter Server. | |
| Invoke-VcenterAuthorizationPermissionsGet | Returns the detailed information about a specific authorization permission in the vCenter Server. | |
| Invoke-VcenterAuthorizationPermissionsList | Queries the authorization permissions in the vCenter Server matching given criteria. |
Bug Fixes
Apart from the exciting new features we have also fixed bugs that were observed in previous PowerCLI releases. Please refer to the release notes for more details.
Installation and Upgrade
Since the module has been renamed to VCF PowerCLI 9.0, it is recommended to uninstall the VMware.PowerCLI module and reinstall VCF.PowerCLI module. Please refer to the release notes for detailed information.
Conclusion
In conclusion, VCF PowerCLI 9.0 marks significant improvements with its enhanced performance, new modules, and auto-generated API bindings, offering a more efficient and powerful automation experience. The improvements in core cmdlets and the addition of essential new features, such as SDDC Manager and NSX VPC, empower users with better control and management capabilities. The integration of Global Authorization APIs further streamlines the automation of role and privilege management. With these updates, alongside various bug fixes, VCF PowerCLI 9.0 not only aligns with the latest VCF version but also sets a new standard for speed, functionality, and ease of use.
Resources
VCF PowerCLI 9.0 – PowerShell Gallery
Release Notes
Changelog for VCF PowerCLI 9.0
PowerCLI SDK examples
Introducing the Hidden Power of the PowerCLI SDK
