Home > Blogs > VMware PowerCLI Blog > Tag Archives: PowerCLI

Tag Archives: PowerCLI

Getting Started with the PowerCLI Module for VMware NSX-T

PowerCLI 6.5.3 was released a few short weeks ago and one of the biggest additions was the module to manage VMware NSX-T! This version of NSX provides network virtualization to not only VMware environments, but also multi-cloud and multi-hypervisor environments too.

Before diving into the module itself, there are a couple things we should cover first. This module was released as a low-level, API access only, module. That means the module comes with the following cmdlets: Connect-NsxtServer, Disconnect-NsxtServer, and Get-NsxtService. The first two cmdlets should be fairly straight forward, but the third is where it gets interesting. The Get-NsxtService cmdlet allows us to have full access to NSX-T’s public API! This module also gives users the capability to use a ‘create’ method to create PowerShell objects. These objects can then be modified and used as input back to the endpoint. This really helps simplify and streamline the interaction between PowerCLI and the NSX-T API endpoint!

For more information about the NSX-T 2.0 release, see the Network Virtualization blog: NSX-T 2.0 is Here!
For more information about the NSX-T 2.0 API, see the VMware Code API Explorer

Getting Started

First things first, open up a PowerShell session and authenticate to your NSX-T Manager with the ‘Connect-NsxtServer’ cmdlet.

Output Example:
Connect-NsxtServer Example

We are now ready to start exploring the NSX-T API with the ‘Get-NsxtService’ cmdlet. Running that cmdlet as is will return every named call for the NSX-T API, so this may be a little overwhelming at first. To make this easier, remember to reference the API Explorer as well as PowerShell’s ‘where-object’ cmdlet to help filter the names for what you need.

Example: Getting NSX-T Manager Information

For the first example, we are looking for information about the NSX-T Manager node. Searching through the VMware Code API Explorer for NSX-T for ‘nsx manager appliance’, we see a ‘GET’ method against ‘/node’ that is probably the most relevant call.

NSX-T API Explorer Example

To consume this in the PowerCLI module, we will use the ‘Get-NsxtService’ cmdlet to search for a name that ends in ‘node’ with the following code:

We can then save that service in a variable to easily reference for future commands:

We can now explore the methods available by piping the ‘nodeSvc’ variable to PowerShell’s ‘Get-Member’ cmdlet. Example:

There, In the output from ‘Get-Member’, we will see a ‘get’ method. We’ll want to perform that with the following code:

Combined Command Example:

Output Example:
NSX Manager Node Information Retrieval Example

Example: Retrieve Transport Zone Information

In our second example, we will retrieve information about the configured Transport Zones. We can do this as easily as we did the NSX Manager node. Referring back to the VMware Code API Explorer for NSX-T, we can search through the available namespaces for ‘transport zones’. We’ll find one in particular that has a description of ‘List Transport Zones’.

Based on that information we can infer that the service name is going to end in ‘zones’. We’ll run the following command to find the service:

We’ll then store the ‘com.vmware.nsx.transport_zones’ service into a variable. We’ll pipeline that variable to the ‘Get-Member’ cmdlet to find the available methods we can use. An example:

This service offers a couple methods which could fit our scenario of retrieving information about the environment’s Transport Zones. The methods available are a ‘get’ and a ‘list’. In order to perform the ‘get’, we would need to have the ID. Since we don’t have that information yet, we’ll run the ‘list’ method and store that into a variable with the following command:

Refering to the ‘tZones’ variable we can see some information, but the info about the Transport Zones themselves are within the ‘results’ property. We can refer back to the ‘tZones’ variable but specifying the ‘results’ property and find the information we’re looking for.

Combined Command Example:

Output Example:
Transport Zone Example

Example: Logical Switch Management

We have now covered much of the basics on how to get started, so let’s start doing some other tasks. In this example, we are going to list out the Logical Switches and then create a new one!

First, we’ll retrieve information about our existing Logical Switches using the knowledge we built from the first two examples. This can be done with the following commands:

Referring back to the output from the ‘Get-Member’ cmdlet, we noticed a ‘create’ method was available. This is where the ‘Help’ property is going to become very important. We can obtain some additional information about the requirements of the ‘create’ method by calling the variable’s ‘help’ property. We can also target the help for our example by further calling the ‘create’ property. We can do that with the following command:

The output includes a lot of valuable information such as the required and optional parameters, expected output, potential errors, and so forth. The last property, ‘logical_switch’, is the important one. We can refer to this as the structure the ‘create’ method is looking for. We can take that a step further and actually create a specification based off of that information as well with the command:

Checking the output of the variable ‘logSwitchSpec’ we can now see a PowerShell object that can be modified to be included as part of our ‘create’ action. The required parameters are the Logical Switch name, Transport Zone ID, and admin state. However, since this is an overlay logical switch, we can also specify the replication mode as noted in the ‘Help’ output. We can make those modifications with the following commands:

Lastly, we will run the original ‘create’ method against the ‘logSwitchSvc’ variable. Example command:

Combined Command Example:

Example Output:
Logical Switch Creation Example

Example: IP Pool Management

The last example will be taking a look at managing IP Pools.

Much like the prior examples, we’ll start by retrieving information about the existing IP Pools with the following commands:

However, we’d like the output to be a little more readable and include information which is nested within a property. This can be accomplished by using PowerShell’s ‘Format-Table’ cmdlet. We will take the ipPools variable output and pipeline that into the ‘Format-Table’ cmdlet. There we can use the ‘property’ parameter to specify only the properties that we are concerned with viewing.

Command Example:

Output Example:
IP Pool Information Retrieval Example

With our custom output, we realize there happens to be an IP Pool which doesn’t have any IPs assigned to it. We’ll want to remove that IP Pool so someone doesn’t try to use it. Performing a ‘Get-Member’ against the ipPoolSvc variable, we see there’s a ‘delete’ method we can use to remove that unneeded IP Pool. To find more information about what the method requires, we can call the ipPoolSvc’s ‘Help’ property and even further specify the ‘delete’ property. There we can see the IP Pool’s ID is the only required input while the ‘force’ input is optional. We are then ready to use the ‘delete’ method with the following commands:

Output Example:
IP Pool Removal Example

Summary:

PowerCLI 6.5.3 introduced a great new module to manage VMware NSX-T environments. In the NSX-T module’s current release, it has three cmdlets to connect and disconnect from the NSX Manager while the third is used to interact directly with the NSX-T API. This blog post went through several examples including retrieving information about the NSX Manager node, Transport Zones, Logical Switches, and IP pools. We then took a look at using the API access to create a logical switch and remove an IP Pool.

Let us know in the comments how you’re using the NSX-T module to manage your environment!

New Release: VMware PowerCLI 6.5.4

It feels just like yesterday that we released PowerCLI 6.5.3. Shockingly, it was less than a month ago when we released the brand-new module to help manage and automate your NSX-T environments. Yet, we’re back with another brand-new module to manage VMware Cloud on AWS environments as well as a bunch of new and updated storage cmdlets too!

PowerCLI 6.5.4 features the following:

  • New module for VMware Cloud on AWS functionality
  • 14 new cmdlets added to the Storage module
  • Several cmdlets have also been improved in the Storage module

Let’s take a closer look at each of these.

New VMware Cloud on AWS Module

VMware Cloud on AWS (VMC) initial availability was announced earlier this year at VMworld US. PowerCLI already works with the vSphere infrastructure out of the box. How about managing the VMC service itself? Doing tasks such as creating SDDCs, adding or removing ESXi hosts, and so forth. PowerCLI 6.5.4 makes all of that possible!

This module is being released as a low-level, API access only, module and will feature the following cmdlets:

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

Note: The VMC API is currently available as a “Technical Preview” and therefore the namespace and functionality provided by the module may change in the future.

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

Copy the refresh token, open a new PowerShell session (after having updated to PowerCLI 6.5.4), and connect to the VMC service with the following command:

Now that we are connected, we can then display some information about the current Organization with the following commands:

Example Output:
Example: Connecting and Listing Current Org

One other thing you probably want to do is retrieve information about the Org’s SDDC. That information can be found with the following commands:

Example Output:
Example: Retrieving an Org's SDDC Information

New Storage Module Cmdlets

The Storage module has added a ton of functionality around vSAN encryption. PowerCLI can now manage Key Management Servers (KMS), configure KMS clusters, manage certificates, and even start the vSAN encryption process on a cluster! There are also a couple of other cmdlets available to repair vSAN objects, obtain evacuation plan information, and manage vSAN rebalance cluster actions.

Here’s a list of all the new cmdlets available:

  • Add-KeyManagementServer
  • Get-KeyManagementServer
  • Set-KeyManagementServer
  • Remove-KeyManagementServer
  • Get-KmsCluster
  • Set-KmsCluster
  • New-KmipClientCertificate
  • Get-KmipClientCertificate
  • Start-VsanEncryptionConfiguration
  • Get-VsanEvacuationPlan
  • Repair-VsanObject
  • Start-VsanClusterRebalance
  • Stop-VsanClusterRebalance
  • Get-VsanRuntimeInfo

Taking a look at some of these new cmdlets in action:

Improved Storage Module Cmdlets

Last, but not least, there are some cmdlets that have received updates for additional functionality. Here’s a list of the improved cmdlets:

Cmdlet Added Functionality
Get-VsanTest Displays vnic and pnic vSAN Stats
Start-VsanClusterDiskUpdate Parameter: EraseDisksBeforeUse
Reformats the vSAN disk with encryption settings
Get-VsanClusterConfiguration Displays the Silent Health Check Statuses and Resync Throttling Configuration of a vSAN Cluster
Set-VsanClusterConfiguration Parameter: AddSilentHealthCheck & RemoveSilentHealthCheck
Allows for Management of vSAN Health Check Silencing Actions
Parameter: ResyncThrottlingMbps
Configures Throttling of vSAN Resync Traffic
Parameter: WitnessHost
Replaces the Witness Host in a Stretched Cluster
Test-VsanClusterHealth Additionally Displays Encryption Health Results

Summary

PowerCLI 6.5.4 brings some fantastic updates to your PowerShell console and only a month after the last update! This release allows you to manage your VMware Cloud on AWS Org, SDDC, and more directly from PowerCLI. There are also a lot of storage improvements to make automating vSAN clusters a breeze and more secure with 14 new cmdlets and several other having been improved upon.

Updating to PowerCLI 6.5.4 is just as easy as:

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

New Release: PowerCLI 6.5.3

I’m excited to announce that it’s release day yet again! We have a great new update for you with PowerCLI 6.5.3! Just a few short months ago, two to be exact, the last version of PowerCLI was released. That release introduced a new parameter, some new content library functionality for ISOs, and even new support for certain features.

PowerCLI 6.5.3 comes packed with the following:

  • New module for NSX-T functionality
  • Addition of a ‘Create’ method for use with the ‘Get-*Service’ cmdlets
  • Several issues have been resolved

Let’s take a closer look at each of these.

New NSX-T Module

PowerCLI 6.5.3 introduces a brand-new module in order to manage VMware NSX-T environments. NSX-T was announced this year at VMworld US. In a nutshell, NSX-T is the newest iteration of VMware’s multi-hypervisor NSX platform. It is also the key to multi-cloud, and container infrastructures!

This module is being released as a low-level, API access only, module and will feature the following cmdlets:

  • Connect-NsxtServer
  • Disconnect-NsxtServer
  • Get-NsxtService

An example of connecting to an NSX-T server and listing the nodes included in the cluster:
NSX-T Module Example Usage

For more information on the NSX-T RESTful API, the API documentation can be viewed on the VMware Code API Explorer.

New Create Method Available

The other major update is around the addition of a ‘Create’ method to the Get-CisService and, newly released, Get-NsxtService cmdlets when used in conjunction with an object’s ‘Help’ property. This streamlines the creation of certain objects for a template-like experience. Those who have worked with specifications when using the ‘Get-View’ cmdlet will be quite familiar with how this ‘Create’ method will work and be interacted with. This method works against the following objects:

  • Parameter
  • Elements of a parameter (Limited to types: List, Set, Optional)
  • Key and value of parameters (Limited to types: Map)
  • Fields of a parameter (Limited to types: Structure)

Here’s an example on how the new ‘Create’ method can be used to create and apply settings to a specification in order to make a new VM while using the vSphere Automation SDK API:

Resolved Issues

This release of PowerCLI also contains some usage improvements to a handful of cmdlets.

  • New-TagAssignment: When connected to multiple vCenters and using string based inputs for the ‘Tag’ and ‘Entity’ parameters, the cmdlet has been updated to no longer throw an error of “The specified parameter ‘Tag’ expects a single value, but your name criteria ‘…’ corresponds to multiple values.”
  • Set-VMHostNetworkAdapter: When configuring an ESXi host’s virtual NIC to use an IPv6 address which is managed through a vCenter Server of version 6.5, the AutomaticIPv6 property has been corrected to no longer flip the switch to ‘True’.

Summary

We are continuing our commitment to getting the latest and greatest functionalities, performance improvements, and issue resolutions with this latest release of PowerCLI 6.5.3. After only 2 months, we have released a new module to manage NSX-T environments, added a new ‘Create’ method for use with the Get-CisService and Get-NsxtService cmdlets, and fixed a handful of issues with existing cmdlets.

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

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

PowerCLI Support Breakdown

Is PowerCLI supported by VMware?
Can support requests be opened about PowerCLI through MyVMware?

Questions like these keep coming up at VMUG meetings and customer meetings. This shouldn’t be a secret! The 18 modules that are available for with the current release of PowerCLI 6.5.2 are covered under VMware’s Basic Support and Production Support scope.

With that said, there are some areas in need of clarification. The coverage areas are around the installation process and cmdlet failures. If you’re running into errors while installing or initializing PowerCLI, a support request can be opened. If you’re using a cmdlet and you’re hitting some form of error, where the command used to work or should work according to the documentation, a support request can be opened. VMware’s Global Support Services (GSS) will work to identify the issue with you.

There are some areas of PowerCLI where GSS does not have the ability to support. These areas are around any guidance for custom scripts and/or advanced functions. VMware does have the ability to offer vSphere SDK Developer Support Service. If you are in need of this service, I would recommend speaking to your VMware account team.

Now that we have the groundwork laid, let’s discuss a little further how to make a support request regarding a PowerCLI issue.

Ask the Community

We’re talking support requests in this blog post, but… Have you asked the community? PowerCLI has a very active community which can be accessed in many ways. First, there’s fantastic PowerCLI VMTN Community that’s open and available to search through and ask questions. It even just recently hit 12,000 discussions! Then, there’s the VMware Code slack channel on PowerCLI is constantly one of the busiest channels in the Slack team and has over 500 members! There’s also Twitter and using the PowerCLI hashtag.

Support Request Creation

In order to help streamline the process of creating a support request to VMware, I’ve compiled some helpful suggestions from both customers whom have submitted support requests and the GSS representatives whom may respond to these support requests.

First and foremost, when creating a support request, you’ll notice there isn’t a “PowerCLI” support section. The best thing to do here is create a support request for product that’s having issues. Example: If it’s a VMHost cmdlet failure, create an ESXi support request.

Isolate the Issue

When creating the support request, only include the specific cmdlet which is not operational. Make sure to also include the output from running the cmdlet, such as the exact error message wording. Also, where possible, attempt to use the ‘Verbose’ parameter to help generate additional informational output.

Example: Using the Verbose parameter

User Resolve-Error

If you are receiving an error, try to make use of the following function after receiving the error:

The Resolve-Error function’s output helps to provide as much context about the error as possible. For more information about it’s origin and usage, please refer to the following: Microsoft PowerShell Blog: Resolve-Error

Include All Version Information

Including all of the necessary version information is a very important step. Part of this would include PowerShell version, PowerCLI module versions, vSphere version, and so forth.

PowerShell information can be found using the built-in variable: $PSVersionTable

Example: Obtaining the version of PowerShell

PowerCLI module version information can be found with the following command: Get-Module –Name VMware*

Example: Listing Modules with Get-Module

If your PowerCLI session is connected to your vSphere environment, obtaining the vCenter version can be done with the following command: $global:DefaultVIServer | select Name,Version,Build

Example: Obtaining the version of vCenter

If you happen to be running into a vSAN PowerCLI issue, obtaining the vSAN version can be obtained through the new Get-VsanView cmdlet. An example command:
(Get-VsanView -Id "VsanVcClusterHealthSystem-vsan-cluster-health-system").VsanVcClusterQueryVerifyHealthSystemVersions((Get-Cluster).Id) | select VcVersion

Example: Obtaining the version of vSAN Cluster

If you happen to be running into a vRealize Operations Manager (vROps) PowerCLI issue, obtaining the vROps version can be a bit tricky. This is because it involves accessing the underlying API. This can be done in two command lines though:
$OmServer = $global:DefaultOMServers[0].ExtensionData
$OmServer.GetCurrentVersionOfServer() | select ReleaseName

Example: Obtaining the current version of vROps

Last one, if you happen to be running into a Horizon View PowerCLI issue, obtaining the Horizon View version can also be a little tricky. However, it can be obtained in two command lines:
$hvserver = $global:DefaultHVServers[0].extensiondata
$hvserver.ConnectionServer.ConnectionServer_list().General | select Name,Version

Example: Obtaining the version of Horizon View Server

Additional Information

Feel free to include any additional information which may help bring the support request to resolution. One example, screenshots are always helpful. If the error involves any variables or pipeline input, include the output for those items as well.

Summary

VMware PowerCLI is supported by VMware and support requests can be opened! VMware supports both the installation process and cmdlet usage. However, to make the support process easier:

  • Open a support request for the product area where the failure is occuring
  • Isolate the problem to the usage of a particular cmdlet
  • When dealing with an error, include the output from the Resolve-Error function
  • Include the versions of all related products (PowerShell, PowerCLI, vSphere, etc)
  • Include any variable and/or pipeline input being referenced

    • Also, don’t hesitate to ask the community! There’s a terrific wealth of knowledge who are eager to help!

What PowerCLI Version Am I On Anyways?

When PowerCLI was converted to modules, it introduced the ability to pick and choose which modules are loaded. Taking it a step further, it also allowed users to specify which versions of those modules are loaded. Historically, PowerCLI was released as one large ‘bundle’ of modules, and was not a great release practice. This meant that even though most modules were not touched, we were still required to go through our release processes to get them out the door. This is not scalable when trying to get features to you more frequently.

With modules in the Powershell Gallery, we can now release individual modules asynchronously from other modules. The first release to really take advantage of that is PowerCLI 6.5.2. For those whom have already updated their VMware.PowerCLI module from the Microsoft PowerShell Gallery, you noticed there were only 3 modules which were updated and needed to be downloaded.

The Better Way

In prior releases, we could use the ‘Get-PowerCLIVersion’ cmdlet and receive a high-level look at the overall PowerCLI version which was installed. Previously, our versioning scheme was not supported in PowerShell, so it took a cmdlet to print the version out (Example: VMware PowerCLI 6.5 R1). That is gone now. We’ve made the change to semantic versioning in 6.5.1. This means there will be no more R1, R2, or R3 releases!

Starting with PowerCLI 6.5.2, the process to get module versions has changed. Running the ‘Get-PowerCLIVersion’ cmdlet now results in a warning message indicating that it is deprecated and to use the ‘Get-Module’ cmdlet instead.

Example of the deprecation notice for Get-PowerCLIVersion

Using Get-Module

There are a couple ways to use the ‘Get-Module’ cmdlet to help us determine our versioning. The reason for that is because the ‘Get-Module’ cmdlet only shows the modules which have been imported.

The first way is to get the overall PowerCLI version, which is dependent on the ‘VMware.PowerCLI’ module. We can determine the version by first importing the module (if it’s not already imported) and then running the following command:
Get-Module -Name VMware.PowerCLI | Select-Object -Property Name,Version

Example: Obtaining the version of the VMware.PowerCLI module

From the above example, we can see that we’re using PowerCLI version 6.5.2.

Another way is to just reference the modules which have been loaded automatically. I have an example where we connect to our vCenter Server and then run the following command to find the versions of all the PowerCLI modules which are in-use:
Get-Module -Name VMware.* | Select-Object -Property Name,Version

Example: Obtaining the version of PowerCLI when using module autoloading

From the above example, we see that we’re only using a single PowerCLI module and it happens to be versioned at 6.5.2.

Running a couple additional, random, commands, we re-run the above command and see there’s now a bit more of a mix amongst our loaded modules.

Example: Obtaining the version of active PowerCLI modules

Summary

The new method to obtain what version of PowerCLI you’re using is through the ‘Get-Module’ cmdlet. This update was made for many reasons. This new method takes advantage of how our the PowerCLI modules can be loaded independently of each other on an as needed basis. It also takes advantage of how the PowerCLI module releases can now be done asynchronously from each other. Lastly, since we’ve changed the PowerCLI versioning over to align with the standard PowerShell versioning, there’s no need for a custom cmdlet anymore!

If you’re using ‘Get-PowerCLIVersion’ in your scripts or modules, make sure you’re aware of this and update your resources to reflect this change!

Updating PowerCLI through the PowerShell Gallery

PowerCLI 6.5.2 has been released! This is the second release of PowerCLI to the PowerShell Gallery, so it’s time to figure out how to update your PowerCLI versions to the latest and greatest.

We’ll cover a couple scenarios:

  • Updating from PowerCLI 6.5.1, installed online from the PowerShell Gallery
  • Updating from PowerCLI 6.5.1, installed offline from the PowerShell Gallery
  • Updating from PowerCLI 6.5 R1 or prior

Updating from PowerCLI 6.5.1, Online

This will be the easiest update process PowerCLI has ever offered! Open a PowerShell session, type the following command:
Update-Module -Name VMware.PowerCLI

Update Module Example

That’s it, you’re now running the latest and greatest PowerCLI release!

However, if you happen to have run into the following error it’s possible that PowerCLI was installed by the offline method:
Update-Module : Module ‘VMware.PowerCLI’ was not installed by using Install-Module, so it cannot be updated.

There’s two main ways to resolve this:
Option 1. Remove the PowerCLI modules from where they currently reside
1a. Run the following command:
Get-Module VMware.* -ListAvailable
1b. There should be a ‘Directory’ label at the top of the response. Browse to that directory and remove all the directories starting with ‘VMware.*’

Example Usage of Get-Module

1c. Perform the following command:
Install-Module -Name VMware.PowerCLI -Scope CurrentUser

Option 2. Use the force… And by that, I mean perform the Install-Module command with the ‘Force’ parameter
2a. Perform the following command:
Install-Module -Name VMware.PowerCLI -Scope CurrentUser -Force

Updating from PowerCLI 6.5.1, Offline

This process will work exactly the same as the installation process.

1. From a computer that has internet access, run the following command:
Save-Module -Name VMware.PowerCLI -Path C:\Path\To\Desired\Folder
2. Take the downloaded modules and make them available to the offline system
3. Copy and replace the individual PowerCLI module folders to the location where the prior modules were placed.

Copying over the PowerCLI modules after saving them locally

Updating from PowerCLI 6.5 R1 or prior releases

If you happen to be running an older version of PowerCLI which involved an MSI installer, we can verify that by running the following command:
Get-Module VMware* -ListAvailable

Example on showing a list of available PowerCLI modules

If the majority of PowerCLI modules are versions listed at 6.5.0 or older, as shown above, proceed through the following steps.

PowerCLI 6.5 R1 (or older) Uninstallation Steps:
1. Uninstall PowerCLI through the Control Panel
2. Browse to the following directory: C:\Program Files (x86)\VMware\Infrastructure\
3. If there is a ‘vSphere PowerCLI’ directory, delete it

Uninstalling Prior PowerCLI Versions

PowerCLI 6.5.2 Online Installation
This works exactly the same as how the installation did for PowerCLI 6.5.1.

Within a PowerShell session, type the following command: $PSVersionTable

PSVersion Table Sample Output

If the PSVersion is a Value of 5.0 or above:
1. Run the following command:
Install-Module -Name VMware.PowerCLI –Scope CurrentUser
2. If asked to update ‘NuGet Provider’, choose ‘Y’ to install and import the newer version.
3. If asked to ‘install modules from an untrusted repository’, choose ‘Y’ to accept.

Install Module usage to PowerCLI 6.5.2

If the PSVersion is a Value of 4.x or 3.x:
1. Install a current version of PowerShellGet through one of the following two options:
1a. Install Windows Management Framework 5.1
1b. Install PackageManagement PowerShell Modules
2. Run the following command:
Install-Module -Name VMware.PowerCLI –Scope CurrentUser
3. If asked to update ‘NuGet Provider’, choose ‘Y’ to install and import the newer version.
4. If asked to ‘install modules from an untrusted repository’, choose ‘Y’ to accept.

PowerCLI 6.5.2 Offline Installation
1. From a computer that has internet access, run the following command:
Save-Module -Name VMware.PowerCLI -Path C:\Path\To\Desired\Folder
2. Take the downloaded modules and make them available to the offline system
3. Copy and replace the individual PowerCLI module folders to one of the following locations:
3a. Local User Usage: $home\Documents\WindowsPowerShell\Modules
3b. All User Usage: $pshome\Modules

Example file structure for an offline PowerCLI Installation

The PowerCLI Installation Walkthrough Video also works in this scenario too. However, following the instructions in the video will now result in PowerCLI 6.5.2 being installed:

New Release: VMware PowerCLI 6.5.2

The past couple releases have introduced some new and exciting modernizations for PowerCLI. We’ve moved from Snapins to Modules, leaving behind registry settings and the need for an installer and making packaging much easier. We then introduced you to PowerCLI installation through the Microsoft PowerShell Gallery, making installation and updates a single command.

All of these lead up to us delivering more frequent releases and more timely features and bugfixes. Only three months ago, we introduced PowerCLI 6.5.1, and today we’re delivering 6.5.2, cutting our release time in half from the past. We still have a lot of work to do on our processes, but we look forward to delivering frequent, high quality releases of the best automation library for VMware!

PowerCLI 6.5.2 has some great improvements. They come in three main areas:

  • Addition of the ‘InventoryLocation’ parameter to the following cmdlets: Move-VM, Import-VApp, New-VApp
  • Ability to mount a Content Library sourced ISO with the New-CDDrive cmdlet
  • Updated Support Around Experimental Features

Let’s take a closer look at each of these.

New Parameter: InventoryLocation

The main purpose of the ‘InventoryLocation’ parameter is to specify a folder the VM or vApp should be placed during their related actions. The expected input for this parameter is a type of ‘FolderContainer’. Previously, the only option was ‘Destination’ and it accepted a folder, ESXi host, cluster, or resource pool. The issue was only one item could be specified at a time. Therefore, this addition is nice because it reduces the total number of steps needed to either move a VM between vCenter Servers or when deploying a new VM/vApp.

First example, moving a VM between vCenter Servers. By default, the VM would be moved to the root of the Datacenter in the ‘VMs and Templates’ view. Technically, it would be moved to the ‘vm’ folder but that’s hidden from the GUI view. This new parameter allows us to skip the follow-up ‘Move-VM’ command and place the VM in the proper folder at time of the migration.

Cross vCenter vMotion Example using Inventory Location Parameter

Second example, creating a new VM by importing a vApp. As with the previous example, this cuts down the steps in deploying this VM and streamlines the process.

Import-VApp example while using the Inventory Location parameter

Using Content Library Sourced ISOs

The ‘New-CDDrive’ cmdlet has a new parameter by the name of ‘ContentLibraryIso’. This allows us to mount an ISO which has been presented through vSphere’s Content Library. Here’s an example:

Example usage of the New-CDDrive cmdlet and Content Library ISOs

vSphere’s Content Library is a great resource and I’m really happy to be able to take better advantage of it through PowerCLI!

Experimental Feature Updates

If you’ve had the chance to read through our documentation, perhaps you’ve noticed a couple of the features or parameters which were marked as experimental. Several of these have been tested and we have been able to remove the functionality’s ‘experimental’ messaging.

Some Examples:

  • Set-HardDisk -ZeroOut: This parameter can be used to zero out a disk when the PowerCLI session is connected directly to the ESXi host.
  • New-HardDisk -AdvancedSetting: The experimental part of this parameter was centered around the Storage Distributed Resource Scheduler (SDRS) rule association.
  • New-VM -AdvancedSetting: The experimental part of this parameter was centered around the SDRS (SDRS) rule association.
  • Install-VMHostPatch: The whole cmdlet was experimental and has been approved for supported usage.

Summary

PowerCLI 6.5.2 is the first of our change to having more frequent releases. While these iterative releases may not be as packed full of new features as all the prior releases, we are able to provide new functionality and resolve any issues faster than prior versions. Some proof of that is the addition of the ‘InventoryLocation’ parameter to several cmdlets, the ‘ContentLibraryIso’ parameter to the New-CDDrive cmdlet, and taking several features and cmdlets from experimental to supported!

Don’t wait, Update-Module today!

Update Module Example

For information on the Microsoft PowerShell Gallery update process, see the following blog: Update PowerCLI From the PowerShell Gallery

For more information on changes made in VMware PowerCLI 6.5.2, including improvements, security enhancements, and deprecated features, see the VMware PowerCLI Change Log. For more information on specific cmdlets, see the VMware PowerCLI 6.5.2 Cmdlet Reference.

Spotlight on the New DRS Groups and VM-Host Rule Cmdlets!

We’re kicking off the first in a series of blog posts taking an in-depth look at some of the new cmdlets that were made available with the PowerCLI 6.5.1 release. This first post is going to be covering the cmdlets targeted at managing DRS groups and their associated rules.

These new cmdlets are as follows:

  • Get-DrsClusterGroup
  • New-DrsClusterGroup
  • Set-DrsClusterGroup
  • Remove-DrsClusterGroup
  • Get-DrsVMHostRule
  • New-DrsVMHostRule
  • Set-DrsVMHostRule
  • Remove-DrsVMHostRule

If you’ve never used DRS groups and DRS affinity rules or don’t know what they are, these are a way to control which VMs are able to exist on which hosts. This control is leveraged through either affinity or anti-affinity rules that are configured at the cluster level. These rules are configured between groupings of VMs and groupings of hosts. These rules also have types, which basically describes how the enforcement should work. The types are: Must Run On, Should Run On, Must Not Run On, Should Not Run On

Please see the documentation for more information about: DRS Affinity Rules

Taking A Closer Look – A Use Case Demonstration

We have been given a lab environment and our end result is to have the even numbered App VMs run on the even numbered hosts whenever possible, and likewise with the odd numbered VMs and hosts.

First, a look at the lab environment:

  • 1 Cluster
  • 4 Hosts
  • 50 VMs

Environment Setup

We’ll start by taking a look at the DRS Cluster Group cmdlets. These are used in order to create, manage, and remove VM and host based DRS groups. These cluster groups are then referenced by the DRS VM-Host affinity rules, which we’ll discuss in a bit.

Let’s create the first host DRS group, which will be for the odd numbered hosts. This can be done with the ‘New-DrsClusterGroup’ cmdlet while specifying a name, the cluster, and the desired hosts. A command for our sample environment looks like this:

Creating a DRS group

We’ll repeat a similar process for the even hosts, only this time we’ll store the cluster and desired hosts in their own variables:
Creating a DRS group

We now have the required host DRS groups, so we can move forward and create the VM DRS groups. These are created with the same ‘New-DrsClusterGroup’ cmdlet, except we’ll now use the VM parameter and specify the VMs for each group.

Starting again with our odd numbered VMs, we’ll use the following command:

Creating a DRS group

If you’ll notice, that’s nowhere close to all of the necessary odd numbered VMs. We’ll now make use of the ‘Set-DrsClusterGroup’ cmdlet to add the remaining VMs (which I’ve already stored into a variable). This cmdlet also requires usage of either the ‘Add’ or ‘Remove’ parameter in order to specify what kind of modification is being requested.

The command to add the remaining odd system should be similar to the following:

Updating a DRS group

We’ll repeat a similar process for the even VMs’ DRS group:
Creating a DRS group

Before moving on to creating the VM-Host affinity rules, let’s review the DRS groups we’ve created to this point with the ‘Get-DrsClusterGroup’ cmdlet.
Displaying the DRS Groups

This cmdlet also has a couple parameters to help gain additional information. The ‘Type’ parameter can be used to specify whether to return VM groups or host groups. The ‘VM’ and ‘VMHost’ parameters can be used to only return DRS groups belonging to that VM or host.

Some examples of these parameters in use:
Filtering the list of DRS groups

Moving on to the creation of the rules… We’ll be using the ‘New-DrsVMHostRule’ cmdlet along with several parameters. These parameters will be ‘Name’, ‘Cluster’, ‘VMGroup’, ‘VMHostGroup’, and ‘Type’. Most of those should be self-explanatory, but ‘Type’ may not be. Thanks to tab complete, we’ll see that the type options are ‘MustRunOn’, ‘ShouldRunOn’, ‘MustNotRunOn’, and ‘ShouldNotRunOn’ and apply to how the rule is enforced against the cluster.

Remembering that our goal is to have the even VMs run on the even hosts whenever possible, we’ll issue the following command:

Creating a VM-Host Rule

We’ll do a similar command for the odd rule:
Creating a VM-Host Rule

Our objective should be complete and we can verify that by using the ‘Get-DrsVMHostRule’ cmdlet. The output should be similar to the following:
Displaying VM-Host Rules

These VM-Host rules can also be modified once they’ve created with the ‘Set-DrsVMHostRule’ cmdlet. This cmdlet has the ability to rename the rule, enable or disable it, and modify either the VMGroup and/or the VMHostGroup.

The rules can easily be disabled using the following command:

Modifying VM Host Rules

This environment happens to be a lab, so before wrapping up this post we should probably clean it up. We can do this while utilizing the ‘Remove-DrsClusterGroup’ and ‘Remove-DrsVMHostRule’ cmdlets. The commands could look like the following:

Cleaning up the lab environment

Summary

These eight new cmdlets are a terrific addition to the PowerCLI 6.5.1 release. They are also a great compliment to the already existing DRS cmdlets! Start using them today and let us know your feedback!

PowerCLI 6.5.1 Installation Walkthrough

We released PowerCLI 6.5.1 two weeks ago and the response has been incredible! The VMware.PowerCLI module is closing in on 4,000 downloads from the PowerShell Gallery and we’ve received a ton of good feedback.

There seems to be quite a few questions and comments over this new installation method so I created a walkthrough video to illustrate the process for PowerShell version 5.0 as well as for versions 3.0 and 4.0. We’ve also collected the most common errors and issues during the installation process and included troubleshooting steps for those below.

Walkthrough Video

Common Troubleshooting Steps

If there happens to be an issue during the installation process, here’s a couple of the top tips we have seen on working around them:

  • The process cannot access the file ‘C:\Users\…\AppData\Local\Temp\…’
    • Ensure previous versions of PowerCLI are uninstalled and all PowerShell sessions are closed.
    • Verify the file isn’t being blocked by an antivirus software.
  • A command with name ‘verb-noun’ is already available on this system.
    • This is due to a module already available on the system containing that cmdlet. The more common example modules include FailoverClusters and HyperV.
    • Append “-AllowClobber” to the Install-Module command line.
      Example: Install-Module –Name VMware.PowerCLI –Scope CurrentUser –AllowClobber
  • No match was found for the specified search criteria and module name ‘VMware.PowerCLI’
    • This could be due to a lack of connectivity to the PowerShell Gallery.
    • If a proxy can be used, the “Install-Module” cmdlet can configure proxy connectivity with the “Proxy” and “ProxyCredential” parameters.
      Example: Install-Module –Name VMware.PowerCLI –Scope CurrentUser –Proxy ‘http://my.proxy.company.com’
  • Could not get response from query ‘https://www.powershellgallery.com/api/v2/package/VMware.VimAutomation.Core/…’
    • This warning is just indicating there is an issue establishing connectivity to the PowerShell Gallery. Retry the installation at a later point in time and it should succeed.

Summary

We are really excited about this release and what this means for the future of PowerCLI! Upgrade to PowerCLI 6.5.1 today, and keep that feedback rolling in!

Welcome PowerCLI to the PowerShell Gallery – Install Process Updates

PowerCLI 6.5.1 has been released and in this release we have made some big changes to the way you install and keep up to date with PowerCLI! This update was all based around Microsoft PowerShell deployment models, listening to you, the customer and ensuring we are making the changes to provide the best PowerShell product going forward.

As of PowerCLI 6.5.1, you no longer have a MSI file to download and install. You can now install directly from the PowerShell Gallery! This update streamlines the install process in multiple ways and allows module based features which PowerShell users will be used to from other PowerShell based additions.

What does this mean for you?

PowerCLI being on the PowerShell Gallery means there are some changes that users should be aware of. The first big change, there is no more MSI to perform the install and therefore you don’t download it from the VMware website!

The install is done completely through PowerShell itself using the PowerShell Gallery via PowerShellGet. This means also means the other items which used to be installed by way of the MSI won’t be installed automatically. These things include the PowerCLI desktop shortcuts and the User Guide.

There are two ways in which you may install PowerCLI with this new method, online and offline. Let’s take a look at how to perform these methods.

Getting Started

The first step in moving to this new release is to uninstall any prior versions of PowerCLI which may be installed on the system by the old MSI installer, this is needed to move to the new distribution model.

Uninstalling Prior PowerCLI Versions

It is also worth checking to ensure the “PowerCLI” folder has been removed from the following directory: C:\Program Files (x86)\VMware\Infrastructure\

With the prior version of PowerCLI uninstalled, it’s time for the install!

Online Installation From a Computer with an Internet Connection

For the online install, start by confirming access to PowerShell Gallery and being able to find the PowerCLI module. This can be done by running the following:

Find-Module Output for PowerCLI

Note: If you have not accessed the PowerShell Gallery before, or perhaps have an out of date version of NuGet, you may receive a message indicating there is a missing or out-of-date NuGet provider. NuGet is a Package Management provider. These are primarily used to install, upgrade, configure, and/or remove software in an automated fashion. To accept the installation of a proper version of NuGet, hit “Y”.

We will now make use of the Install-Module cmdlet to make PowerCLI actually available on the local system. This can be done with the following:

You will notice we’re only installing it for the current user, we do this because it doesn’t require admin access! If you would like it available for all users of the computer, your PowerShell session will have to be running as an administrator, and PowerCLI will automatically be installed for all users by changing the Scope parameter to AllUsers.

Install-Module usage

Success! We now have the PowerCLI modules installed and available locally!

Offline Install of PowerCLI to a Computer Without an Internet Connection

The following method should be used to install PowerCLI through the PowerShell gallery for those systems which do not have access to the internet. You will need at least one system that has internet access and a way to move the files to the target computer.

While on a system that has internet access, we will find the PowerCLI module with the same command we ran above:

Then we can download the module for offline consumption with the following command:

Save-Module Output

At this point, we’ll want to copy those downloaded folders and place them on the system without internet access in a location where PowerShell can find them, this is the modules folder and can be confirmed by typing $ENV:PSModulePath at the powershell prompt.

Using PowerCLI

One of the great enhancements in PowerCLI 6.5.1 means we no longer need to load the modules into the PowerShell session as we may have done in the past, as soon as the modules are loaded into the module folder PowerShell will automatically be aware of their existence and you will find the cmdlets registered with the PowerShell session. Normal PowerShell behaviour meanst that as soon as you use the first cmdlet the PowerCLI module will be loaded as needed.

But what about the nice PowerCLI Welcome message and other functions which existed to make PowerCLI easier to use when we launched the old desktop icon?

First, we can mimic the desktop shortcuts by simply running:

Import-Module VMware.PowerCLI Output

Please note the warning message about joining the Customer Experience Improvement Program (CEIP). We recommend enabling CEIP, as it’s greatly helps us improve our products! In order for the message to not appear, you either have to enable or disable CEIP by way of the Set-PowerCLIConfiguration cmdlet.

The other option to load the cmdlets, simply use the cmdlets as you normally would. The modules will auto-populate as necessary!

Here’s an example of using a new PowerShell session and connecting to a vCenter Server:

PowerCLI Autoloading Example

We can see the session begins without any PowerCLI modules being imported. After typing in the Connect-VIServer cmdlet (tab complete is fully operational as well), we can see the VMware.VimAutomation.Core module has been imported automatically! The other modules won’t be imported until they’re referenced.

Re-Creating The Desktop Shortcut

I know there are quite a few fans of the Desktop shortcut, so I’ll briefly describe how to set that up. First, create a shortcut that points to the PowerShell executable and place it on the desktop. Next, right click the newly created desktop shortcut and select properties. You should find yourself on the “Shortcut” tab. Enter the following values:

In the end, we should have something quite similar to the following:
Recreating the PowerCLI Desktop Shortcut

Summary

This new install method is a very exciting improvement for PowerCLI. As seen above, this definitely streamlines the process of getting PowerCLI installed and accessible!

To find out more about the other fantastic improvements that are available with VMware PowerCLI 6.5.1, please see the following blog: New Release – PowerCLI 6.5.1