Skip to content

Category: VMware

Finding a VM’s Port-ID with PowerCLI

A question was recently brought up over finding a VM’s Port-ID with PowerCLI.

Right off the bat, I assumed the ask was for the distributed switch port. That wasn’t the case though. In this situation, the ask was to identify the Port-ID that was being displayed in ESXTOP via the Network view.

ESXTOP Network View Example

The Port-ID that’s being displayed is local to the host. That information isn’t available through the VM object, at least as far as I could find. In order to get the Port-ID through PowerCLI, we have to get a little crafty. This is going to require some ESXCLI usage.

Since we’re dealing with networking, we can automatically jump to the ESXCLI Network documentation on VMware Code. Luckily, there’s really only two commands that deal with VMs and we’re going to need both of them:

  • network vm list
  • network vm port list

We’ll use the network vm list command to obtain the VM’s World-ID and then use that as an input to the network vm port list command to receive back the local Port-ID for the VM!

Since the goal was to do this in PowerCLI, I created a script and added it to the PowerCLI Community Repo. The script is titled: Get-VMNetworkPortId.ps1

It can be used in a couple different ways, so use it however makes sense to you.

Example Usage:
Get-VMNetworkPortId Usage

After feeding in a VM by pipeline, making use of the VM parameter, and even passing multiple VMs to the script, we can see how the Port-ID does in fact match up with what’s displayed in the ESXTOP example from above.

The script is available on GitHub and looks like the following:

Learn Log Insight’s REST API with Postman!

Getting started with a new API is always… interesting. Here lately, I have found myself getting a lot better acquainted with Log Insight. If you’ve never heard of it, this is a log management solution from VMware.

Anyways, when I first start using an API I like to read through the docs and try some basic calls. Log Insight’s API documentation is pretty solid. However, when it turned time to start actually making some calls, I then had a wealth of tools at my disposal to make calls. This is a good problem to have!

I’m still new to this API, so I’m looking for the path of least resistance. Enter the Postman, a free REST Client. My favorite part of Postman is the ability to use Collections. These Postman Collections are literal collections of API calls that can then be exported/imported and shared.

I created a Log Insight collection and have shared it on GitHub: Log Insight Postman Collection

Prepping the Client

Prerequisite: Have the Postman desktop client installed. (I haven’t tested this in the Chrome app)

We can start using this collection by heading out to my GitHub Repository and downloading it in your preferred method. For this example, I’ll be downloading it as a ZIP file.

Download GitHub Repo

Extract the ZIP to a location of your choosing.

Open Postman, click the “Import” box (alternatively, File -> Import)

Import Postman Collection to Client

Select the “Log Insight.postman_collection.json” file

Select appropriate JSON file

We will see a new folder titled “Log Insight” which contains 49 requests:

Sample Collection View

Preparing Environmental Variables

Another great reason to use Postman is the ability to use environmental variables. I highly recommend using these as it will greatly simplify the experience.

We will need to create the following variables:

  • li – this will be the Log Insight node we’ll be making calls against
  • auth – this is the authorization string that is referenced in each call’s header

To create these variables, we’ll need to go to the gear icon towards the top right corner and select “Manage Environments”

Manage Environments Option

On the “Manage Environments” section, click “Add”

Manage Environments Layout

We can then give the environment a name and start filling in those variables I listed above (since we do not yet have a Session ID, the auth variable will be left blank), then click “Add”

Log Insight Demo Environment Setup

We can now close out of the “Manage Environments” section by clicking on the “X”

We now want to configure Postman to reference these variables. To do this, we will select the “Environment” dropdown box and select the environment we just created.

Choosing to use the new Log Insight Demo Environment


The first call we’ll want to perform is to authenticate to the Log Insight node and receive our Session ID.

To do this select the “Sessions” folder, then click on the “Login” request.

Exploring the Session Login Request

We’ll now select the “Body” tab. Here we’ll see a preformed body in JSON format. Modify the values to match that of your environment.

Exploring a sample body

We can now click “Send” to actually perform the API call

Example response

If all goes well, you’ll receive a status of “200 OK” and a result like the above.

Now that we have our session ID, we’ll need to fill in our “auth” variable so that we can start easily using the Log Insight API.

Copy the sessionId value within the quotations and head back to the “Manage Environment” section.

Click on the Environment we created earlier, then click into the “Value” section for the “auth” variable:

Update Environmental Variables

Referencing the Log Insight API documentation on authentication, for the Authorization variable we will want to type “Bearer” followed by a space and then the sessionId value

Example Auth variable for the Environment

Click “Update” then close out of the “Manage Environment” section by clicking on the “X” in the top right corner

Making Log Insight API Calls

At this point we have our Postman Collection imported, our session is authenticated, and our variables are set! We can now start making calls to the Log Insight node.

Example: Finding out what authentication providers are available

Select the “Auth-Providers” folder, click “List”, then click “Send”

Auth Providers Sample Response

Example: Obtaining a list of Events

Select the “Events” folder, click “List”, then click “Send”

Sample Events List Response

One Last Thing

There’s a couple areas where appears to be a variable, but it’s not one that we’ve configured.

Example: Within the “Licenses” folder there’s a “Remove” request.

Clicking on the request gives us the following for the request URL:

Exploring License Removal Request

Noting the “{license}” portion of the URL, this section is supposed to be overwritten with an actual value. If we reference the above screenshot, we can see that there is an “Example” we can refer to (top right corner, beneath the “Manage Environments” icon).

Clicking on that example button will take us to an example of what the call will look like along with a sample response.

Exploring License Removal Request Example


Getting started using an API can be a lot of things. This Postman Collection should be a great resource to start learning and using the Log Insight API. I know I learned a lot by creating and using it. If there’s any suggestions or additional examples you’d like to see, please submit an Issue against the repo with those notes. Better yet, contribute back by forking the repo and creating a pull request with those updates!

EUC Day 2016: PowerCLI for View

The Minneapolis VMUG had a terrific idea to put together a specialized event based around End User Computing (EUC) and I was lucky enough to be asked to come and present something around automation.

That brings me to the session I chose, which is an introduction to PowerCLI for View. Horizon View and automation (Powershell, specifically) aren’t something that go together all that well at this point in time. PowerCLI for View is a great utility, don’t think I’m taking anything away from it nor bashing it, but it does take some understanding to kinda set the groundwork before you dive-in head first. This session is my attempt to help set that groundwork.

Thanks again to Matt Heldstab and the rest of the MN VMUG team for having me out, the event was awesome. I also want to call out the rest of the sessions from that day, which can be found on YouTube:

PoSh – vCenter License Handling

It’s that time of year again for vExperts… Time to replace the NFR licenses the vExpert program has graciously supplied us.

Was given a gentle reminder of this the other day while preparing for a vBrownbag presentation:
Expiring Licenses

I’ve been on a big Powershell module making binge lately and noticed there really isn’t much for handling vCenter’s licensing, so I created one and published it out on Github.

An overview of what’s currently included in the module:

Function Name Description
Get-VILicenses Gathers information on all VI licenses availabe in the vCenter Server
Get-VILicenseInfo Gathers information on the supplied license key
Add-VILicense Adds the supplied license key to the vCenter Server license inventory
Remove-VILicense Removes the supplied license key from the vCenter Server license inventory
Set-VILicense Sets the supplied license key to the desired VI Object
Get-VILicense Gathers information on the supplied license key from the VIObject

A general walk-through of what’s occurring within each function is Powershell interfacing with the License Manager object via VMware’s SDK.

PowerCLI modules and/or PSSnapins
Active connection to a vCenter Server

An automated way of downloading the files into a dedicated directory and importing the module into the current session:

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

PowerCLI – Quick Stats Not Up To Date Error

Recently rebooted one of my vCenters and came across an error on my ESXi hosts stating “Quick stats on *vmhost* is not up-to-date”. A couple seconds worth of googling brought me to VMware KB2061008 which helped to resolve the issue.
Quick Stats Error Message

However, the KB only went through the GUI process of adding in the requisite parameters but there’s no fun in clicking through the GUI so I came up with a short script that’s applicable to vCenter 6.0 which can also accomplish performing the parameter creation/updates for the KB’s workaround.

Once you run the script, you’ll still need to restart the vCenter service on your VCSA or Windows server. If you happen to be in the web client:
Go to “Administration” then to the “Deployment” area to select “System Configuration”
Select “Services”, then select “VMware vCenter Server”
Select “Actions” followed by “Restart”

Once the service is back up and running the error will no longer be present.
vCenter Service Restart

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

PoSh – NSX Module Update

A new update has been published to the NSX Module which I previously published on GitHub:

A reference to the first blog post I made concerning the module, including some screenshots of it actually in use:

The module has now grown to 31 of the following cmdlets:

Cmdlet Description
Get-NSXController Gathers NSX Controller details from NSX Manager
Get-NSXControllerUpgrade Gathers NSX Controller Upgrade details from NSX Manager
Get-NSXEdge Gathers NSX Edge Node details from NSX Manager
Get-NSXEdgeDefaultRoute Gathers NSX Edge Node default route details from NSX Manager
Get-NSXEdgeFeatures Gathers NSX Edge Feature details from all nodes within NSX Manager
Get-NSXEdgeFirewall Gathers NSX Edge Node firewall details from NSX Manager
Get-NSXEdgeInterfaces Gathers NSX Edge Node’s Interface details from NSX Manager
Get-NSXEdgeNATs Gathers NSX Edge Node NAT details from NSX Manager
Get-NSXEdgeRoutingOverview Gathers NSX Edge Routing Overview details from all nodes within NSX Manager
Get-NSXEdges Gathers NSX Edge Node details from NSX Manager
Get-NSXEdgeStaticRoute Gathers NSX Edge Node static route details from NSX Manager
Get-NSXEdgeUplinks Gathers NSX Edge Uplink details from all nodes within NSX Manager
Get-NSXIPPools Gathers NSX IP Pool details from NSX Manager
Get-NSXIPSets Gathers NSX IP Set details from NSX Manager
Get-NSXLogicalSwitches Gathers NSX Logical Switches and their details from NSX Manager
Get-NSXManager Gathers NSX Manager details
Get-NSXManagerComponents Gathers NSX Manager component details
Get-NSXManagerSSH Gathers NSX Manager SSH component details
Get-NSXScopes Gathers NSX Scopes and their details from NSX Manager
Get-NSXSSOConfig Gathers NSX SSO details from NSX Manager
New-NSXIPPool Creates an NSX IP Pool within NSX Manager
New-NSXIPSet Creates a new NSX IP Set within NSX Manager
New-NSXLogicalSwitch Gathers NSX Logical Switches and their details from NSX Manager
Remove-NSXEdge Deletes an NSX Edge Node from NSX Manager
Remove-NSXIPPool Removes an NSX IP Pool within NSX Manager
Remove-NSXIPSet Removes an NSX IP Set within NSX Manager
Remove-NSXLogicalSwitch Gathers NSX Logical Switches and their details from NSX Manager
Remove-NSXSSOConfig Removes NSX SSO config from NSX Manager
Restart-NSXManager Configures the NSX Manager for reboot
Set-NSXManagerSSH Configures NSX Manager SSH component
Update-NSXEdge Updates the NSX Edge via Update parameter

If you need an automated way of downloading the files into a dedicated directory and importing the module into the current session please see the following:

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

PowerCLI 6.0 R2 – Announcing vROps Integration!

For those that have been requesting some vCOps and/or vROps integration into PowerCLI, as I have been, we finally have our solution! PowerCLI 6.0 R2 brings that to the table in the form of a new module: VMware.VimAutomation.vROps

The following functions are featured in the module:

Here’s a couple tips to get started using it:
To begin pulling stats you will need to authenticate to the vROps instance via Connect-OMServer:

After getting connected, and being connected to an associated vCenter, check out the resources via Get-OMResource by piping it a VMHost, VM, or so forth:

As you can see, I pulled the resources for a VMHost. Some of the basic, higher level, information is in there such as Health status and value, whether or not vROps is receiving any data about it, and how far back data has been collecting for the resource.

The following is pulling the same information for the vROps VM in my lab environment:

If you want to go straight to the stats, I don’t blame you one bit. However just running the Get-OMStat command is going to fill your PoSh window with every single stat available for that resource at all the time points available. Overwhelming would be putting it lightly, so you’ll want to also familiarize yourself with Get-OMStatKey. This function allows you to see what all stats you can actually pull:

Couple things I feel the need to point out:

  • Include both the AdapterKind and ResourceKind objects when calling this function, it returns every possible stat key possible without it… All 17,646 of them.
  • Even when including the AdapterKind and ResourceKind, I would highly recommend filtering out what what you’re looking for. The HostSystem ResourceKind has 2225 stat keys alone.

Finally, lets select a stat key and pull some detailed stats by way of the Get-OMStat function. In this scenario, I’m pulling CPU Ready Summation values:

Some of the other functions included surround alerting.

The Get-OMAlert function pulls all of the vROps alerts:

Since there happens to be some alerts, let’s check out two abilities of the Set-OMAlert function. The first option being cancelling of an alert:
set-omalert -Cancel

If you notice in the example, the alert still exists but it’s status is changed to “Inactive”.

Next up, let’s check out the suspend function of the Set-OMAlert function:
Set-OMAlert -SuspendMinutes

Overall, the new module definitely gets my stamp of approval! Thanks to the Automation and PowerCLI team for listening to the users and getting this integrated!

Additional information is available at the following link:

PoSh – Gathering VMware NSX Info via API

I’ve been lucky enough to get a chance to do some work involving VMware’s NSX product lately. Having watched a bunch of VMworld sessions, live demos and messed around with it in the VMware Hands on Labs I was fairly comfortable in an existing environment. However I’ve gotten fairly used to using Powershell to do most of my work and there doesn’t appear to be much out there in the way of cmdlets or functions.

Chris Wahl has some really good resources regarding using Powershell to do API calls with NSX to both gather controller information (Creating NSX API Calls with PowerShell – Wahl Network) and create/remove virtual network tiers (Leveraging PowerShell to Deploy Virtual Network Tiers with VMware NSX – Wahl Network).

Thanks to Chris’ first post, I’ve taken what he created and built out a couple additional functions and even dumped them all into module form.

An overview of what’s currently included in the module:

Function Name Description
Get-NSXController Will inventory all of your controllers from NSX Manager
Get-NSXEdges Will inventory all of your Edge Nodes from NSX Manager
Get-NSXEdgeFeatures Will inventory all of your Edge Nodes’ Features from NSX Manager
Get-NSXEdgeInterfaces Will inventory the selected Edge Node’s Interfaces from NSX Manager
Get-NSXEdgeNats Will inventory all of your Edge Node’s NATs from NSX Manager
Get-NSXEdgeRoutingOverview Will inventory all of your Edge Nodes’ Routing Overview details from NSX Manager
Get-NSXUplinks Will inventory all of your Edge Nodes’ Uplinks from NSX Manager

A general walk-through of what’s occurring within each function is Powershell using the Invoke-WebRequest cmdlet against the NSX Manager’s REST API and formatting what’s returned into an easy to consume format that is a similar match to what’s returned back by way of the “Networking and Security” plugin.

Powershell 3.0 or better: Invoke-WebRequest first appeared in Powershell version 3.0, so anything less won’t work.
NSX Manager Admin credentials: All of the information is being pulled directly from the NSX Manager
Import the module by way of the .psd1 file: while not really a requirement, it certainly helps with the formatting of the output

Example of how the formatting is handled, first with the .psd1 file then with the .psm1 file:
Loading NSX PSD1 vs PSM1

Link to the GitHub repo location:

An automated way of downloading the files into a dedicated directory and importing the module into the current session:

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

vSphere SSO – Removal of Additional Application Users

Have you ever logged into the vSphere Web Client and received a warning like this:
Could not connect to one or more vCenter Server systems

This “Could not connect to one or more vCenter Server systems” error means the web client cannot talk to vCenter server. In this case, the server having the error was decommissioned and no longer exists.

To resolve this issue, head into the “Administration” area of the web client. Follow that by going to the “Single Sign-On” area and select “Users and Groups”. From there, hit the “Application Users” tab and take a look at the users. In this case there were a total of three vCenters and their associated Inventory Services:
Application Users

While in the above screen, take note of the last 6 characters of each user.

Prior to removing any of those user account it’s time to verify those user accounts against the services still in existence. This information is hidden a bit, so some digging is required.

For the vCenterServer Service account, look for the “solutionUser” section of the following file: C:\ProgramData\VMware\VMware VirtualCenter\vpxd.cfg

For the InventoryService account, again, look for the “solutionUser” section of the following file: C:\Program Files\VMware\Infrastructure\Inventory Service\lib\server\config\
Inventory Service User Account

Once the user account information has been gathered, head back to the “Application Users” section and remove the accounts that were not able to be verified:
Remove vCenterServer Account
Remove InventoryService Account

Once removed, log out of the vSphere web client and log back in and the error message will no longer be displayed across the top of the screen.

PowerCLI – View – Pool Health Check Report

I’ve been given the chance to work with View a little more here recently and focus in on some of the gaps that are missing, specifically around reporting and alerting. vC Ops and the View adapter are in use, however the alerts leave much to be desired. I’m glad to be able to say that the gaps are filled in with the new version, and new title, of vR Ops and the View adapter but this environment is not yet to that point.

Examples of the vR Ops alerts which are included by default:

vR Ops Default View Alerts

What gaps am I referring to? I’m aiming specifically at the View Pool state, provisioning state and the amount of available desktops compared to the headroom configuration.

To do this, I enlisted the help of the View PowerCLI cmdlets and the View Connection server ADAM database to create the script below that creates an output similar to this:
(Note: the asterics around the value that caused the report to be sent)

View Pool Report Output

Before getting to the script, lets cover some of the requirements of the script:

  • This script is to be run from a Connection server.
  • This script is currently formatted to have the report be consumed by way of email.
  • The email variables need to be filled in to match the environment it’s being run in.
  • The email is sent only if the following criteria are met:
    • A Pool’s state is false.
    • A Pool’s provisioning state is false.
    • A Pool’s available desktops are less than the headroom setting by the amount set in the desktopthreshold variable.
  • The default desktop threshold is meant to be a percentage and is set to a default of 90%, or 0.9. This is easily modified on line 22.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.