Home > Blogs > VMware PowerCLI Blog

New Release: VMware PowerCLI 10.1.1

It’s release day and we have another terrific update ready for you. VMware PowerCLI 10.1.1 includes some very important updates specifically for the Horizon View folks!

PowerCLI 10.1.1 includes brand new support for Horizon View 7.5. This is quite significant because Horizon View was released just a few short weeks ago and had quite a few amazing updates as well. More information about the Horizon View 7.5 release is available: Horizon 7.5 View Release Notes

PowerCLI 10.1.1 Support for Horizon

There are two other notable improvements which came thanks to the community! The first is around an issue where users were receiving ‘insufficient privileges’ when attempting to connect to the Horizon View server. The second is around an issue where users would occasionally receive an error message of ‘the request channel timed out while waiting for a reply after 00:01:39.9969495’. Both of these have been updated and should now work as intended!

Summary

VMware PowerCLI 10.1.1 is continuing to show the evolution in our processes to be able to bring the latest and greatest features to you faster and faster. With this release, there are new APIs available from Horizon View 7.5 plus a couple improvements to the way PowerCLI interacts with the Horizon View server.

It’s as simple as ‘Update-Module -Name VMware.PowerCLI’ to update your PowerCLI version!

Sample: Update-Module -Name VMware.PowerCLI

For more information on changes made in VMware PowerCLI 10.1.1, including improvements, security enhancements, and deprecated features, see the VMware PowerCLI Change Log. For more information on specific product features, see the VMware PowerCLI 10.1.1 User’s Guide. For more information on specific cmdlets, see the VMware PowerCLI 10.1.1 Cmdlet Reference.

Configuring Per-VM EVC with PowerCLI

vSphere 6.7 was released a couple weeks ago and there were a ton of new features announced. However, there was one feature I was particularly interested in and that was Per-VM EVC (Enhanced vMotion Compatibility).

Giving a brief, high-level overview, EVC can be used to set a baseline of CPU features available to a VM or a set of VMs. In the past, this was a cluster-based setting. It was really nice because you could take hosts which didn’t have the same CPUs, use EVC to apply a common CPU baseline, and still put them in a cluster to take advantage of features like DRS and HA. The problem is that once a VM left that cluster, the EVC configuration would no longer be enforced. With vSphere 6.7 that changes, EVC can now be applied at the VM object level. This is awesome because now a VM can move across clusters, across datacenters, or even out to VMware Cloud on AWS and remain powered on and compatible! Be on the lookout for a much deeper dive on Per-VM EVC by my counterpart Emad Younis shortly.

Currently, configuring a VM’s EVC mode with PowerCLI is only available through a low-level command. That means, to configure this setting, we’re going to need to use methods that are exposed through either Get-View or a VM’s ExtensionData.

Let’s take a look at how we can automate this new setting using PowerCLI!

Introduction

First things first, we need to cover some requirements. To configure Per-VM EVC we need a couple things, including:

  • vSphere 6.7 (vCenter and ESXi host version)
  • A VM with hardware version 14
  • PowerCLI 10.1.0

Once we have those all inline, we need to figure out what EVC mode is appropriate for this particular VM.

Determining the Desired EVC Mode

PowerCLI makes it extremely easy to figure out what EVC modes are available. Each ESXi host object has a top-level property we can use to discover what their maximum EVC mode is. Once we obtain that information from all the potential hosts, we choose the lowest baseline and configure the VM with that.

Obtaining an ESXi host’s maximum EVC mode can done with the following command:

Example: Discovering VMHost MaxEVCMode

From the above example, we can see that the VM’s EVC mode should be no higher than ‘intel-sandybridge’ to work on these hosts. If we anticipate moving this VM between vCenters, we would want to run the same command against the ESXi hosts managed by that vCenter. If we anticipate moving this out to VMware Cloud on AWS, we already know those hosts are configured to be at an EVC mode of ‘intel-broadwell’. Broadwell is a higher, more advanced, mode than Sandy Bridge, so we’re still going to use the Sandy Bridge mode for our VM.

For more details about each EVC mode and how they rank, see the following KB article: 1003212 – Enhanced vMotion Compatibility (EVC) processor support

Assigning EVC Mode

We’re now ready to configure the per-VM EVC mode for this particular VM. The method we’ll be using is ‘ApplyEvcModeVM_Task’. More information about this can be found in the vSphere 6.7 Web Services API: ApplyEvCModeVM_Task

Based on the documentation, we have a couple parameters available to use:

Parameter Type
mask completeMask
HostFeatureMask object Boolean

The ‘mask’ parameter is looking for the CPU masking features we wish to configure. This is where the API gets a little more advanced than the UI. Where the UI only allows us to set the top level EVC mode, the API enables us to either specify all the feature masks which correlate to the EVC mode or be as granular as to only specify specific masks, the choice is ours. To be clear, this method does not accept the top-level EVC mode as input. Personally, I configure all the feature masks so that the VM’s level is aligned with the top level EVC mode.

The second parameter is ‘completeMasks’. This parameter is essentially asking if the masks presented are the complete list of masks to enable for this VM. This parameter accepts true or false as input and defaults to true. This is another reason I, personally, specify all the feature masks because then there is no confusion over what is or is not enabled for the virtual machine object.

Before we run the method, we need to obtain a list of feature masks. Starting from a high level, we can obtain the EVC Modes which are supported by our present vCenter with the following command:

To only retrieve information about the ‘intel-sandybridge’ mask, we can add a ‘where’ statement searching for that as the ‘key’ property:

Then, to isolate the masks we will be using as inputs for the ‘mask’ parameter, we can store the ‘FeatureMask’ output into a variable:

The above can also be wrapped up into a one-liner with the following command:

We’re now ready to run the command as follows:

Putting It All Together

If we combine all of the code above, it will look like the following:

Example: Putting everything together to set Per-VM EVC mode of a single VM

In 6 lines of code, we’ve gone from a VM with no EVC mode to a VM configured with an EVC mode of ‘intel-sandybridge’!

Community Module

If you found all the above to be a little too cumbersome, there’s a community module you can use to simplify this entire process. This module is available on the PowerCLI Community Repository: PerVMEVC

The PerVMEVC module provides the following three functions:

  • Get-VMEvcMode
  • Remove-VMEvcMode
  • Set-VMEvcMode

Here’s an example of them in action:
Example: Community Module Usage

Summary

vSphere 6.7 came packed with new features. One feature in particular really enables VMs the mobility to run anywhere. That feature is Per-VM EVC. This new feature takes the cluster based EVC functionality we’re already familiar with and now makes it available at the VM object level. PowerCLI gives us the ability to automate the entire process through the API using the ‘ApplyEvcModeVM_Task’ method as well as a new community module that can be used to simplify the process!

Let us know in the comments what you think of Per-VM EVC mode!

New Release: VMware PowerCLI 10.1.0

April has been a release heavy month for VMware. We have seen releases for vSphere 6.7, the entire vRealize suite, Site Recovery Manager 8.1, Horizon 7.4.1, and quite a few more. As of today, PowerCLI is being added to that list with the release of 10.1.0!

PowerCLI 10.1.0 offers the following updates:

  • Support for vSphere 6.7
  • Support for NSX-T 2.1
  • New VMware.Vim module
  • New cmdlets for managing Auto Deploy script bundles

Let’s take a look at those and some of the other updates.

Updated Support

Compatibility is something very important to PowerCLI. PowerCLI version 10.1.0 adds support for both vSphere 6.7 and NSX-T 2.1. This update gives you access to continue automating the latest and greatest VMware releases, plus have access to all those new APIs!

PowerCLI Compatability

New Module

This new version of PowerCLI brings our 20th module! This new module is named: VMware.Vim The goal of this module is to be able to allow you to have access to the latest vSphere APIs, including those available as part of VMware Cloud on AWS.

New Auto Deploy Cmdlets

Auto Deploy has two new cmdlets available to help with management of script bundles. These new cmdlets are:

  • Set-ScriptBundleAssociation
  • Remove-ScriptBundle

The Set-ScriptBundleAssociation cmdlet allows us to configure ESXi hosts to be associated with specific Auto Deploy script bundles.

The Remove-ScriptBundle cmdlet allows us to remove script bundles from Auto Deploy in an automated fashion. This functionality was actually requested by the community as PowerCLI Idea 114, so it’s really cool to see the direct impact the community can have.

General Updates

There’s a number of other improvements available in PowerCLI 10.1.0 as well. The first of which is to allow Import-VApp to support SHA-256 and SHA-512 hash algorithms. Next, we have deprecated the ‘Version’ parameter for the New-VM and Set-VM cmdlets. This parameter has been replaced by ‘HardwareVersion’. The same deprecation has been applied to the VirtualMachine object as a whole. Instead of referencing the ‘Version’ property, reference the ‘HardwareVersion’ property instead. Then, the Get-TagAssignment cmdlet has had the functionality corrected so we can query tags on datastore clusters. Another shout out to the community for this update, since that’s how this was brought to our attention! Also, we have made some updates to the process of migrating a VM to a VMware Cloud on AWS environment.

Lastly, PowerCLI 10.0.0 brought a bit of a change when it comes to handling vCenter and ESXi certificates. Instead of producing a warning when connecting to resources using invalid or self-signed certificates, PowerCLI now produces an error. We found some valid certificates were still producing an error and have corrected that process with PowerCLI 10.1.0.

If you do need to change PowerCLI’s configuration for handling certificate validation, the following code can be used to ignore those invalid or self-signed certificates:

Wrap-Up

PowerCLI 10.1.0 is the second release of the year and its only April! This release brought support for both vSphere 6.7 and NSX-T 2.1. A new module was introduced, VMware.Vim, making PowerCLI 20 modules strong. Two new cmdlets were added to help in the management of Auto Deploy script bundles! Plus, there were a number of other improvements added as well.

Remember, updating your PowerCLI modules is now as easy as ‘Update-Module VMware.PowerCLI’.

Example: Update-Module to PowerCLI 10.1.0

For more information on changes made in VMware PowerCLI 10.1.0, including improvements, security enhancements, and deprecated features, see the VMware PowerCLI Change Log. For more information on specific product features, see the VMware PowerCLI 10.1.0 User’s Guide. For more information on specific cmdlets, see the VMware PowerCLI 10.1.0 Cmdlet Reference.

New Release: PowerCLI 10 Poster!

The release of VMware PowerCLI 10.0.0 was another big one for us. As a result, PowerCLI is now available on Linux, MacOS, and Windows! As part of every major release, there’s a large number of asks for the PowerCLI poster and today we’re releasing it!

The poster features a bit of a layout refresh which conforms to a more standardized poster sizing guideline, but still features all of our cmdlets, some basic examples, and links to helpful resources.

PowerCLI Poster

New Release: PowerCLI Poster

If you’re looking to print one out, they are best at 36 inches wide by 24 inches tall.

Be on the lookout for these posters coming to a VMworld and/or VMUG near you!

Let us know where you’re putting your poster and how you’re using it either in the comments or on Twitter by mentioning the PowerCLI account!

New Release: PowerCLI Preview for VMware NSX-T Fling

A new Fling has been released for PowerCLI! The PowerCLI Preview for NSX-T Fling adds 280 high-level cmdlets which operate alongside the existing NSX-T PowerCLI module.

What do I mean by ‘high-level’ cmdlets? There are generally two forms of cmdlets available through PowerCLI, high-level and low-level. High-level cmdlets abstract the underlying API calls and provide an easy to use and understand cmdlet, like Get-LogicalSwitch. Based on that, you can assume the output will be logical switches. However, every API call does not have a corresponding high-level cmdlet and that’s where the low-level cmdlets come into play. Low-level cmdlets interact directly with the API and therefore have complete coverage of the available API calls. An example of a low-level cmdlet would be Get-View, or in the case of the NSX-T module it would be Get-NsxtService. More information about the low-level cmdlet usage of the NSX-T module is available in the following blog post: Getting Started with the PowerCLI Module for VMware NSX-T

Why is this being released as a fling? This module is still being developed and we need your feedback! What cmdlets are you using the most? What should the output look like? What cmdlets aren’t working the way you think they should? What cmdlets are missing? As well as any other feedback you can come up with! The preference is to leave the feedback on the fling’s comments section. However, if you post it as a comment here, I’ll make sure the right people receive it.

With that said, let’s get started using this new module!

Geting Started

First, we’ll need to head out to the VMware Flings site, browse for the fling and download the zip file. Direct link: PowerCLI Preview for NSX-T Fling

Next, extract the module and place it into one of your $PSModule directories. Better yet, do it with PowerShell:

We can then verify the module was placed in the proper location and is available for us to use:

Unzipping the Fling download

Note: If you don’t see the VMware.VimAutomation.Nsxt module, you probably need to install the latest version of PowerCLI. Walkthroughs on how to do that are available:

Now that we can see the module, I would suggest browsing through all of the 280 cmdlets available in the module. We can do that with the following command:

Browsing through all the available cmdlets in the Fling Module

One last step before starting to use the new cmdlets, we need to authenticate to the NSX-T server. This requires the VMware.VimAutomation.Nsxt module because it makes available the ‘Connect-NsxtServer’ cmdlet. We can authenticate to the NSX-T server with the following command:

Authenticating to the NSX-T Management Server

We are now authenticated and ready to start pulling information from the environment. Following along with the prior blog post, let’s start by pulling information about our cluster. We can do that with the ‘Get-ClusterNodeConfig’ cmdlet.

Example: Get-ClusterNodeConfig

We can clean up the output through the use of the ‘Select-Object’ cmdlet with the following command:

Example: Simplifying output for Get-ClusterNodeConfig

Another item we looked at in the last blog post, Transport Zones. The ‘Get-TransportZone’ cmdlet can be used, however if we want to clean it up a bit we can run the following command:

Example: simplified output for Get-TransportZone

One last example, we’ll get the status of the cluster. This can easily be done with the ‘Get-ClusterStatus’ cmdlet. However, the results are probably not what you expect. The ControlClusterStatus and MgmtClusterStatus each have an additional nested property of ‘Status’ which we’ll need to gain access to for this to really make sense. To do that, we’ll create a custom dynamic property with PowerShell! These custom properties will be made of hashtables used as part of the ‘Select-Object’ cmdlet. Each hashtable will need a ‘Name’ and an ‘Expression’. Here’s an example of this concept with the ‘Get-ClusterStatus’ cmdlet:

Example: Get-ClusterStatus and handling nested property values

Summary

There’s a great new fling available called the PowerCLI Preview for NSX-T Fling. This fling adds an additional 280 high-level cmdlets for VMware NSX-T, like Get-TransportZone, which means that automating NSX-T has never been easier!

As with all of our Flings, please leave feedback on the Comments section! We want to know what you think. What cmdlets are you using the most? What should the output look like? What cmdlets aren’t working the way you think they should? What cmdlets are missing? As well as any other feedback you can come up with!

Installing PowerCLI 10.0.0 on MacOS

PowerCLI 10.0.0 was released just a few weeks ago and one of the key updates was the added support for MacOS and Linux operating systems. It’s still amazing to think about! PowerShell and PowerCLI available to users on OSes other than just Windows. Wow!

Let’s put this to action and get PowerCLI installed on a MacOS system.

Prerequisite: Installing PowerShell Core – Package

The minimally required version for MacOS is PowerShell Core 6.0.1. There’s a couple different ways to install PowerShell onto a MacOS system. This first method is downloading the PowerShell package and installing it through GUI installer.

We can start by browsing to the PowerShell GitHub repository, and clicking on the ‘Releases’ button. Alternatively, here’s a direct link: PowerShell Releases page

Example: PowerShell Repo Releases Page

On the PowerShell Releases page, we will want to download the latest MacOS package to our local system. Now, we will want to run through the installer. Accepting all of the defaults worked in my environment.

Example: PowerShell Core Package Install

Prerequisite: Installing PowerShell – Homebrew

The other main way of installing PowerShell is through Homebrew. Homebrew is a package manager. It will easily allow us to install, update, and remove packages, like PowerShell, directly from the command line!

If you don’t already have Homebew installed, it too can be installed from the command line with the following within Terminal:

Next, we’ll need to install Homebrew-Cask. Homebrew-Cask is extension of Homebrew to allow for the downloading of additional, pre-compiled, applications. We will perform the install with the following command within Terminal:

Now, we’re ready to install PowerShell onto our MacOS system! This can be done with the following command within Terminal:

Example: Installing PowerShell Core through Homebrew Cask

Installing PowerCLI

We have our prerequisite of PowerShell installed on our MacOS system. We’re now ready to install PowerCLI!

Start by opening Terminal and starting our PowerShell session by entering:

Example: Launching the PowerShell Core terminal

At this point, we’re in PowerShell so we install PowerCLI just like we have for the past couple versions!

Example:

Example: Installing PowerCLI with PowerShell Core

At this point, we’re all set! We can start using PowerCLI just like we normally have on Windows systems for years!

Example: Connecting to a vCenter Server

Couple Things to Keep in Mind

There are still a couple things to keep in mind as you move forward in the excitement of having PowerCLI on a non-Windows system. PowerShell Core, as well as the underlying .NET Core, are not feature complete to their non-Core counterparts. Make sure to test your scripts thoroughly prior to using them. A recent example that was brought up within the PowerCLI channel in the VMware Code Slack group: ConvertFrom-SecureString doesn’t currently work, as per Issue 1654. Therefore, if you have any scripts containing secure string objects, PowerShell Core will not be able to decrypt them.

The PowerCLI 10.0.0 release starts with support for the following modules, and the rest of the modules will be added over time:

  • VMware.VimAutomation.Cis.Core
  • VMware.VimAutomation.Common
  • VMware.VimAutomation.Core
  • VMware.VimAutomation.Nsxt
  • VMware.VimAutomation.Vds
  • VMware.VimAutomation.Vmc
  • VMware.VimAutomation.Sdk
  • VMware.VimAutomation.Storage
  • VMware.VimAutomation.StorageUtility

Some cmdlets, even though they may be in the above list, also still may not function properly. Examples:

  • Get-VICredentialStoreItem
  • New-VICredentialStoreItem
  • Remove-VICredentialStoreItem
  • Get-VMHostHardware
  • Open-VMConsoleWindow

Wrap-Up

The PowerCLI 10.0.0 release added the much requested support for MacOS and Linux systems! In this blog, we walked through two different methods to make PowerShell Core available on MacOS and how to install PowerCLI.

Let us know what you’re most excited about now that PowerCLI works on multiple OSes!

PowerCLI Docker Image Updated

With the official releases of PowerShell 6 Core and PowerCLI 10.0, I am happy to announce that the PowerCLICore Docker image has been updated with all the latest packages!

In the new build, we’re running the latest PhotonOS container, more streamlined than ever! Our PhotonOS team has been hard at work making it easy to install PowerShell on PhotonOS v2:

In addition to the latest PowerShell, we’re installing PowerCLI 10, PowerNSX, and PowerVRA from the Microsoft PowerShell Gallery, making future updates extremely easy!

The PowerCLI Example Scripts are in there too! The modules are installed and ready to use, and the example scripts from the community are in /root.

So what are you waiting for? Take it for a spin today!

New Release: VMware PowerCLI 10.0.0

We are only two months in to 2018, but it has already been pretty exciting from an automation standpoint. Let’s review some of the big news. Microsoft open-sourced and released PowerShell 6.0. They also made it available on a number of operating systems, from Windows to Linux to Mac OS. Then, PowerCLI hit 2,000,000 downloads from the PowerShell Gallery! Today, we are releasing VMware PowerCLI 10.0.0!

Let’s talk about the version change for a second. If you’ve been a PowerCLI user for a couple years, you have probably noticed quite the transformation here recently. One item of note was when the name was changed from vSphere PowerCLI to VMware PowerCLI. This was due to PowerCLI’s ability to manage more than just vSphere. With this release, we are taking that next step to remove ourselves from being in lockstep with vSphere’s versioning. Why did we go with 10? Well, PowerCLI recently celebrated its 10th birthday so it seemed like the perfect number!

Time to take a look at everything that’s new!

Multi-Platform Support

PowerCLI 10.0.0 adds support for Mac OS and Linux! The only pre-requisite is to have PowerShell Core 6.0 installed. The installation process is also the same:

PowerCLI 10 Install Example on a MacOS System

This release brings support for the following modules:

  • VMware.VimAutomation.Cis.Core
  • VMware.VimAutomation.Common
  • VMware.VimAutomation.Core
  • VMware.VimAutomation.Nsxt
  • VMware.VimAutomation.Vds
  • VMware.VimAutomation.Vmc
  • VMware.VimAutomation.Sdk
  • VMware.VimAutomation.Storage
  • VMware.VimAutomation.StorageUtility

Future releases of PowerCLI will continue to add support for the remaining modules.

Default Certificate Handling

This version changes the way certificates are handled when connecting to a vCenter server or ESXi host with the Connect-VIServer cmdlet. If your connection endpoint is using an invalid certificate (self-signed or otherwise), PowerCLI would previously return back a warning. The handling has been updated to be more secure and now return back an error.

If you are using an invalid certificate, you can correct the error with the ‘Set-PowerCLIConfiguration’ cmdlet. The parameter needing to be configured is ‘InvalidCertificateAction’ and the available settings are Fail, Warn, Ignore, Prompt, and Unset.

The following code will configure the ‘InvalidCertificateAction’ parameter to be Ignore:

Deprecated Cmdlets and Property

There are five cmdlets being deprecated. These cmdlets are found in the VMware.VimAutomation.Core module. They are:

  • Get-VMGuestNetworkInterface
  • Set-VMGuestNetworkInterface
  • Get-VMGuestRoute
  • New-VMGuestRoute
  • Remove-VMGuestRoute

These cmdlets are replaced with the use of the Invoke-VMScript cmdlet.

Sample code to change the IP Address of a Windows VM:

One other deprecation is to the Client property. If you have any scripts that are making use of the ‘Client’ property, you’ll want to get those updated to use the ServiceInstance managed object. More information can be found at the following: ServiceInstance

Resolved Issues

First, I want to thank the community for this section. There was an overwhelming amount of feedback that came in and I’m quite excited about how many items we were able to get resolved! Let’s check some of them out:

  • Piping the Get-Datacenter cmdlet output to Get-Cluster now works when more than one datacenter is present
  • Configuring manual MAC addresses with the New/Set-NetworkAdapter cmdlet now accepts all addresses, not just MAC addresses in the 00:50:56 range
  • VMs with snapshots can be Storage vMotioned to VMFS6 datastores without hitting a ‘redoLogFormat’ error
  • Lots of updates to the Get-TagAssignment cmdlet, including when connected to two vCenter Servers and also displays the Tag Category as expected

Summary

Today, we release PowerCLI 10.0.0. This release adds support for PowerShell Core 6 which can be run on Linux and Mac OS systems. There are also a handful of VMGuest related cmdlets which have been removed from the release. Their functionality can be replaced with the usage of Invoke-VMScript. Lastly, there have been several corrections. Many of which are thanks to our amazing community for bringing them to our attention.

Remember, updating your PowerCLI modules is now as easy as:

For more information on changes made in VMware PowerCLI 10.0.0, including improvements, security enhancements, and deprecated features, see the VMware PowerCLI Change Log. For more information on specific product features, see the VMware PowerCLI 10.0.0 User’s Guide. For more information on specific cmdlets, see the VMware PowerCLI 10.0.0 Cmdlet Reference.

Getting Started with the VMware Cloud on AWS Module

VMware Cloud on AWS is a new on-demand service that enables you to run applications across vSphere-based environments plus access to a broad range of AWS services. PowerCLI already helps to automate your VMware Cloud on AWS tasks! This includes tasks such as creating SDDCs, adding or removing ESXi hosts, managing firewall rules, and so forth.

The VMware Cloud on AWS (VMC) module was released as a low-level, API access only, module and will feature the following cmdlets:

  • Connect-VMC
  • Disconnect-VMC
  • Get-VmcService

Let’s take a look at how we can get started using this new module.

Getting Started

When getting started with the VMC module, we’ll notice immediately that it has a little different authentication process than the other PowerCLI connection cmdlets. This module requires you first acquire the OAuth Refresh Token from the VMware Cloud Console:
Example: VMware Cloud on AWS Console - OAuth Refresh Token

Copy the refresh token, open a new PowerShell session, and connect to the VMC service with the following command:

Now that we are connected, let’s start by doing some discovery. The more you work with this module, and the VMC API as a whole, the more you’ll notice the need to be able to easily recall the organization (Org) ID. Therefore, let’s start by looking into how we can discover information about our org. First, we want to figure out what the service is itself with the ‘Get-VmcService’ cmdlet. Notice that we can use the standard PowerShell filtering and wildcard usage to help make the discovery process a bit simpler. Example code:

Next, we’ll make use of the ‘Get-Member’ cmdlet which will show us the available properties and methods for each issued command. We can pipeline the return from the ‘com.vmware.vmc.orgs’ service to the ‘Get-Member’ cmdlet and discover there’s a ‘Get’ and a ‘List’ method available. Since we don’t have any current information about the Orgs within this environment, we’ll opt for the ‘List’ method. Example code:

Example: Service and Org Discovery

Now that we have our org information, the next thing we will want to discover is information about the org’s SDDC. That information can be found with the following commands:

Example: SDDC Discovery

Notice, there’s quite a bit of information to parse through. Let’s look at a simple way to pull out some information about the SDDC’s ESXi hosts. Example code:

Example: ESXi Host Information

VMware Cloud on AWS uses NSX under the covers to provision all of the networking. Therefore, we will also want to have an understanding of the Edge nodes that are available in the environment. This information is actually in a separate service. Remembering what we’ve done previously, here’s some example code to discover some basic information about the SDDC’s Edge nodes:

Example: NSX Edge Discovery

Another good area to be aware of in your SDDC are the firewall rules. These are also easily retrievable through the ‘Get-VmcService’ cmdlet as well. Example of the firewall rules associated with the edge-2 node:

Example: Firewall Rule Discovery

Last example, let’s do something exciting! How about we automate the creation of an SDDC? This is going to require quite a bit of what we’ve learned so far, plus some new tricks. We can find the ‘Create’ method against the com.vmware.vmc.orgs.sddc service. We see that input requires the Org ID and an ‘sddc_config’ input. This is where it gets tricky.

If we remember back in the PowerCLI 6.5.3 release, there was the addition of the ‘Create’ method to a couple cmdlets. This method is also available with the ‘Get-VmcService’ cmdlet. The whole point of this method is to allow us to create a specification in an easy manner. For this example, we’re reference the ‘sddcSvc’ variable, the ‘Help’ property, then the create property. This shows us a property of ‘sddc_config’. This is the specification we’ll need to use. The ‘sddc_config’ property has this ‘Create’ method available so we can automatically build out the specification. Pretty simple, right?

We’re not quite done quite yet though. Each SDDC can have multiple VPC subnets. Therefore, we also need to populate the spec’s customer_subnet_ids list object with the ‘Add’ method.

Example code:

Example: SDDC Creation

The output above from our last create method is a task object. There’s a service for those too! Since the call we made is asynchronous, you can also have a bit of fun and build a progress checker as well!

Here’s some example code I tossed together while waiting on the SDDC to deploy:

Example: SDDC Creation Progress Output

Summary

VMware Cloud on AWS is a fantastic new service that enables you to run applications across vSphere environments as well as accessing a broad range of AWS services. Within this service, PowerCLI is one of the best ways to automate your VMware Cloud on AWS tasks! In this blog post we covered how to discover the available services, explore was methods are available as actions against each of those services, and how to start interacting with those services. We obtained detailed information about our organization, that org’s SDDC and its accompanied configuration including firewall rules, and then had some fun while deploying a brand new SDDC!

Check PowerCLI’s functionality in your own VMware Cloud on AWS environment today and let us know your feedback!

PowerCLI Beta

The PowerCLI Beta containing support for MacOS and Linux is LIVE!

How to participate:

  1. Log in to the VMware Community and read this first!
  2. Join the Community discussions in the beta forum
  3. Join us on VMware {Code} Slack in the #PowerCLI channel!

That’s it for now! Happy Automating!

❤️Jake