I’m working on a project that requires direct interaction with the vRO API from a third party system. Maybe I’m getting less effective at using Google in my old age, but I had a heck of a time finding good solid code for authenticating to the API using anything, including PowerShell.

Typically I’d use Invoke-vRARestMethod from PowerVRA for this, but unfortunately I had some additional requirements that mandate me using a bearer token.

As a point of reference, you can view all of of the available APIs for vRealize Automation by navigating to this url: https://{your-vra-url}/automation-ui/api-docs/. We’ll be working with the “Orchestrator” API

The function below will return a bearer token, which you can use in future API calls to vRA.

Param’s:
Line 3: vra_server – the fqdn of your vRA 8 instance
Line 4: password – password associated with your vRA 8 account used to authenticate. As mentioned, please be smart here. Plantext passwords are bad.
Line 5: username – Unlike vRA 7, vRA 8 needs you to split your username and domain apart. For example, in vRA 7 you’d authenticate using the username jon.smith@rainpole.com, where in vRA 8 you authenticate using just the username jon.smith
Line 6: domain – This is where the domain goes (Example: rainpole.com)

Lines 14-24: We’re setting the body up to be included in the rest request. There’s some special formatting required so we’re using the replace method to modify the string.

Line 27: Build a simple variable with the URI used for authentication. More can be found on this in the API documentation mentioned above.

Lines 29-35: Make the API call, build the bearer token (essentially add the word “Bearer ” to the beginning of the authentication token), and return it.

Short and sweet. I’ll be adding some more snippets and problems in the future.

It’s the network team’s fault…

The Scenario

Imagine you have an environment that has hundreds of VLANs. When you build a new cluster, there’s a real possibility that one host out of many is mis-configured on just a single port group or VLAN. It’s a pretty simple issue, but it’s like finding a needle in a haystack. Because of that, it’s incredibly difficult to troubleshoot, so I wrote a script to run through every ESXi host, and test connectivity on each port group.

If you haven’t used RVTools before, I’d definitely suggest taking a look. In case you’re one of the few that has not used it, it’s a quick tool to generate a point-in-time report of the inventory/configuration/health of a vSphere environment. While it’s one of the best tools out there for a quick and dirty report of an environment, the challenge I often face is that it outputs too much data. The other challenge I’ve faced is that it’s incredibly difficult to combine and analyze data from multiple outputs.

I’ve been working on a project that uses the -runasync parameter on the move-vm cmdlet. The obvious problem with running jobs asynchronously is that you lose the ability to determine the status of whatever task as soon as you submit it.

Use PowerCLI To determine the ESXi host with the most available RAM.

After posting yesterday about modifying the parent image to allow for hostname changes, I was still looking for something a little more streamlined. I remember reading about the new REST API that is available on workstation, so I wrote a little script to use the Workstation API to clone a VM.

Continue reading “Clone VM in Workstation 15 Pro via REST API using Powershell”

I recently encountered an issue in vSphere 5.5 where I wasn’t able to change the interface speed on an ESXi host from auto-negotiate to anything else. After a good amount of troubleshooting I was able to determine that this issue was occurring due to the fact that the NIC firmware version and driver version on a blade server was out of date. VMware has a good KB article on how to grab the firmware and driver versions that I followed. However, the problem is that even on the most modest ESXi host that isn’t running 10G to it, you’ll likely have a minimum of 4 NICs on it. This means that you’ll have to enable SSH on every host you want to check, run one command per NIC each of them (or run a one line script that loops through them, but will that really save you time..?). It doesn’t take a very large cluster for that to become a very large endeavor.

This PowerShell script will connect to a vCenter server, allow you to scan all ESXi hosts, or only hosts within a particular cluster, and output the results in object format so that you can manipulate them how you wish.

Continue reading “VMware Powercli – Gather NIC Driver and Firmware Versions from Hosts via vCenter”

I like having documentation, but I hate creating documentation.  I’ll be the first to admit that I’m slightly lazy at times, however, my own personal preferences for what I’ll call “Effort Allocation”, are not the root of my dislike for creating documentation.  The issue really stems from the fact that creating it is very time consuming, tedious, and usually lower on the priority list.

However, sometimes it’s not you that failed to create the documentation. Consultants frequently fall into this category.

The issue I’m handling here is documenting CDP information from the perspective of ESXi hosts using PowerCLI.

Continue reading “Use VMware PowerCLI to Pull CDP information from ESXi Hosts”