Interacting with VMware vCO and the Rest API using PowerShell – getting a list of workflows

Recently I needed to get a list of VMware vCO workflows from a remote server using PowerShell. A colleague of mine pointed me in the right direction by providing me with a URL to access the vCO Rest API on, as well as letting me know what I needed to send in order to authenticate.

To connect and retrieve content back in the PowerShell example below, we’ll need to:

  • Access the Rest API URL for Orchestrator using a web client object
  • Send basic authentication in the header of our request

Notes:

One thing I did notice is that when you use your web browser to test the URL, the result is returned to you as XML, however when I used a web client object in PowerShell, I got a result returned to me in JSON. The PowerShell script below is therefore tailored to interpret the result as JSON. This being so, you’ll need to make sure you are using PowerShell 3.0 or above, as the ConvertFrom-Json cmdlet is only available using PowerShell 3.0 and above.

When sending your authentication details with the web client object request, make sure your username/password combo are used in this format:

Authorization: Basic username:password

This means that your header you add to your web client option, should be added with the string as per the above, but with the username:password part encoded using base64. The script below takes this all into account, and all you need to do is provide your username and password for vCenter Orchestrator to the PowerShell function, it will handle the base64 encoding and passing of the values to the web client itself.

Anyway, enough of that, let us get onto the actual script itself. This is presented as a PowerShell function. Load it into your session (copy-paste) or add it to your PS profile for future use. Apologies for the formatting – Syntax Highlighter really messes with the formatting and nice clean indentation I normally have in my scripts!

Here is a direct download of the PowerShell script if the script paste below doesn’t work for you:
[wpdm_file id=31]

 

Function Get-VcoWorkflow() 
{

<#
.SYNOPSIS
Fetches vCO Workflow information and details from a vCenter Orchestrator server

.DESCRIPTION
Fetches vCO Workflow information and details from a vCenter Orchestrator server

.PARAMETER Username
Username for the vCO server

.PARAMETER Password
Password for the vCO server

.PARAMETER Server
The vCO server hostname or IP address

.PARAMETER PortNumber
The port to connect on

.EXAMPLE
PS F:\> Get-VcoWorkflow -Username Sean -Password mypassword -Server 192.168.60.172 -PortNumber 8281

.LINK

http://www.shogan.co.uk

.NOTES
Created by: Sean Duffy
Date: 30/03/2014
#>

[CmdletBinding()]
param(
[Parameter(Position=0,Mandatory=$true,HelpMessage="Specify your vCO username.",
ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
[String]
$Username,

[Parameter(Position=1,Mandatory=$true,HelpMessage="Specify your vCO password.",
ValueFromPipeline=$false,ValueFromPipelineByPropertyName=$true)]
[String]
$Password,

[Parameter(Position=2,Mandatory=$true,HelpMessage="Specify your vCO Server or hostname.",
ValueFromPipeline=$false,ValueFromPipelineByPropertyName=$true)]
[String]
$Server,

[Parameter(Position=2,Mandatory=$true,HelpMessage="Specify your vCO Port.",
ValueFromPipeline=$false,ValueFromPipelineByPropertyName=$true)]
[ValidateRange(0,65535)] 
[Int]
$PortNumber
)

process 
{
$Report = @() | Out-Null

# Craft our URL and encoded details note we escape the colons with a backtick.
$vCoURL = "https`://$Server`:$PortNumber/vco/api/workflows"
$UserPassCombined = "$Username`:$Password"
$EncodedUsernamePassword = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($UserPassCombined))
$Header = "Authorization: Basic $EncodedUsernamePassword"

# Ignore SSL warning
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

# Create our web client object, and add header for basic authentication with our encoded details
$wc = New-Object System.Net.WebClient;
$wc.Headers.Add($Header)

# Download the JSON response from the Restful API, and convert it to an object from JSON.
$jsonResult = $wc.downloadString($vCoURL)
$jsonObject = $jsonResult | ConvertFrom-Json

# Create a blank Report object array
$Report = @()

# Iterate over the results and transform the key/value pair like formatting to a proper table.
# Note I use a hashtable to populate a new PSObject with properties, using values found in the original JSON result
foreach ($link in $jsonObject.link)
{
	$kvps = $link.attributes
	$HashTable = @{}
	$kvps | foreach { $HashTable[$_.name] = $_.value } # foreach item in the link object, populate the hashtable
	$NewPSObject = New-Object PSObject -Property $HashTable # Create a new PSObject and populate the properties/values using our hashtable

	# Add our populated object to our Report array
	$Report += $NewPSObject
}

return $Report

}
}

I hope that this script comes in handy, and gives you an idea as to how you can retrieve and convert data from vCO and its RESTful API for use in PowerShell 🙂

Results example after running the Function:
get-vcoworkflow-results

 

Three PowerCLI scripts for information gathering – VMs, Hosts, etc

 

I was on a vSphere upgrade review engagement recently, and part of this involved checking hardware and existing vSphere VI was compatible with the targeted upgrade.

To help myself along, I created a few PowerCLI scripts to help with information gathering to CSV for the VI parts – such as Host Versions, build numbers, VMware tools and hardware versions, etc… These scripts were built to run once-off, simply either by copy/pasting them into your PowerCLI console, or by running them from the PowerCLI console directly.

They can easily be adapted to collect other information relating to VMs or hosts. To run, just launch PowerCLI, connect to the VC in question (using Connect-VIServer) and then copy/paste these into the console. The output will be saved to CSV in the directory you were in. Just make sure you unblock the zip file once downloaded if you execute them directly from PowerCLI, otherwise the copy/paste option mentioned above will work fine too.

There are three scripts bundled in the zip file:

  • Gather all hosts under the connected vCenter server and output Host name, Model and Bios version results to PowerCLI window and CSV
  • Gather all hosts under the connected vCenter server and output Host name, Version and Build version results to PowerCLI window and CSV
  • Gather all hosts under the specified DC and output VM name and hardware version results to PowerCLI window and CSV

Short and simple scripts, but hopefully they will come in handy to some. As mentioned above, these can easily be extended to fetch other information about items in your environment. Just take a look at the way existing info is fetched, and adapt from there. Also remember that using | gm (get-member) on objects in PowerShell is your friend – you can discover all the properties and methods on PowerShell objects by using this, and use those to enhance your reports/outputs in your scripts.

[wpdm_package id=’2025′]

 

Updated: Get VMware tools versions by ESXi host version – a PowerCLI function to map tools version codes to readable version numbers

Quite some time ago I created a PowerCLI function to help me determine VMware Tools versions of queried VMs using PowerCLI. The tools version is returned as a 4 digit number by the vSphere API, and subsequently, so does PowerCLI. This makes determining VMware Tools versions at a glance, a bit of a hassle.

The original function was able to output Tools versions up to ESXi 4.1 u1 or u2, and this week was the first time I had a good use case for this script. I needed more up to date mappings, so I have updated the function to work with VMware tools versions all the way up to ESXi 5.5 now.

Here is the latest script:

# Mapping file found at: http://packages.vmware.com/tools/versions

Function Get-VMToolsMapped() {

 Get-VMToolsMapped -VM MYVMNAME

.EXAMPLE
PS F:\> Get-VMToolsMapped MYVMNAME

.EXAMPLE
PS F:\> Get-VM | Get-VMToolsMapped

.EXAMPLE
PS F:\> Get-Cluster "CLUSTERNAME" | Get-VM | Get-VMToolsMapped

.LINK
http://www.shogan.co.uk

.NOTES
Created by: Sean Duffy
Date: 05/02/2014
#>

[CmdletBinding()]
param(
[Parameter(Position=0,Mandatory=$true,HelpMessage="Specify the VM name you would like to query VMware Tools info for.",
ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
[String]
$VM
)

process {

$Report = @()
New-VIProperty -Name ToolsVersion -ObjectType VirtualMachine -ValueFromExtensionProperty 'config.tools.ToolsVersion' -Force

$VMInfo = Get-VM $VM | Select Name, ToolsVersion
Switch ($VMInfo.ToolsVersion) {
	9344 {$ESXMapping = "esx/5.5"}
	9226 {$ESXMapping = "esx/5.1u2"}
	9221 {$ESXMapping = "esx/5.1u1"}
	9217 {$ESXMapping = "esx/5.1"}
	9216 {$ESXMapping = "esx/5.1"}
	8396 {$ESXMapping = "esx/5.0u3"}
	8395 {$ESXMapping = "esx/5.0u3"}
	8394 {$ESXMapping = "esx/5.0u2"}
	8389 {$ESXMapping = "esx/5.0u1"}
	8384 {$ESXMapping = "esx/5.0"}
	8307 {$ESXMapping = "esx/4.1u3"} 
	8306 {$ESXMapping = "esx/4.1u3"} 
	8305 {$ESXMapping = "esx/4.1u3"} 
	8300 {$ESXMapping = "esx/4.1u2"}
	8295 {$ESXMapping = "esx/4.1u1"}
	8290 {$ESXMapping = "esx/4.1"}
	8289 {$ESXMapping = "esx/4.1"}
	8288 {$ESXMapping = "esx/4.1"}
	8196 {$ESXMapping = "esx/4.0u4 or esx/4.0u3"}
	8195 {$ESXMapping = "esx/4.0u2"}
	8194 {$ESXMapping = "esx/4.0u1"}
	8193 {$ESXMapping = "esx/4.0"}
	7304 {$ESXMapping = "esx/3.5u5"}
	7303 {$ESXMapping = "esx/3.5u4"}
	7302 {$ESXMapping = "esx/3.5u3"}
	default {$ESXMapping = "Unknown"}
	}

$row = New-Object -Type PSObject -Property @{
   		Name = $VMInfo.Name
		ToolsVersion = $VMInfo.ToolsVersion
		ESXMapping = $ESXMapping
	}
$Report += $row
return $Report

}
}

If you have any issues copying and pasting the script from this post, here is a direct download you can use too:

[download id=”28″]

 

Working with the vCenter Server Simulator 5.5 – configuring custom ESXi hosts

Working with VCSIM (vCenter Server Simulator)

 

William Lam has done some excellent blog posts on using the simulator included with the VCSA (vCenter Server Appliance), to setup a simulated vSphere environment. Just the other day at VMworld Europe, he presented a session for vBrownBag entitled “NotSupported Tips/Tricks for vSphere 5.5“. In this session he introduced the new simulator, he dubs “VCSIM 2.0”, which is the latest iteration included with the VCSA 5.5 appliance.

I had previously had a brief look at the VCSIM included with 5.1, but after seeing its limited functionality, did not pursue its use for development testing. However, after learning about the features introduced in VCSIM “2.0”, I just had to take a further look…

To see how to setup and start VCSIM, have a read of Will’s blog post here. However, at a high level, this is what you need to do to start the simulator with defaults:

  • Deploy and fully configure the VCSA 5.5 appliance. Make sure DNS (forward and reverse) is working and the embedded database is properly configured, otherwise the vpxa service will have trouble intialising
  • Ensure you have no issues with the embedded DB being reset (i.e. don’t do this on a production VCSA!)
  • SSH in to the appliance
  • issue command: vmware-vcsim-start default

 

Customising the default VCSIM ESXi host model

 

Today, I needed to replicate a certain condition in our lab environment. Specifically, I needed the ESXi hosts to have 32 CPU cores. By default the ESXi hosts that are simulated have 8 cores. I did a bit of digging around in the /etc/vmware-vpx/vcsim/model folder and figured out which files were referenced when launching the simulator with the default option. By default, the host model in the ESX50 folder is used, so naturally, in order to configure custom ESXi hosts, we need to edit the files within this folder.

Initially, I found one file, “HostHardwareInfo.xml” and changed the CPU core count value to 32. This appeared to work – starting up the sim, and looking at the Web Client, I saw that the simulated hosts were now showing 32 CPU cores. I also changed the RAM up to 32GB (from the default of 16) just to test another option, and this was also showing up. However, upon loading up the MOB (Managed Object Browser), and navigating to the these hosts, I saw that the properties under the host summary->config->hardware were telling another story – they were still set to 8 cores and 16GB RAM. A little more digging revealed that another file, “HostListSummary.xml” also needed to be updated.

So in order to setup your custom ESXi host models for the default VCSIM profile, make sure you update both of these files.

The files to update your default ESXi model
The files to update your default ESXi model

 

Here is the small change I made to increase the Host core count to 32 cores.

<cpuInfo>
    <numCpuPackages>2</numCpuPackages>
    <numCpuCores>32</numCpuCores>
    <numCpuThreads>4</numCpuThreads>
    <hz>2999654793</hz>
 </cpuInfo>

And the data reflected in the MOB:

ESXi Host Hardware Summary

 

Changes as seen in the vSphere Web Client:

vSphere Web Client Host Hardware Summary

Make sure you backup these files before changing them, so that you can roll back if you need to. There are other ways of creating your own profiles for the simulator, but I could not find any documentation on how to create custom hosts. The only bits I could find were relating to creating your own datastores. You can also use the default profile template to create your own profile in it’s entirety, and this is a better long term solution, however to get things up and running quickly with the default profile, the above works nicely.

Note that all properties and methods pertaining to each managed object found in the API appear to be set up and created when using the VCSIM, so this makes a great development/testing/lab tool. Kudos to VMware for releasing this with the VCSA, and thanks to William Lam for pointing it out and blogging about it!

VMworld Europe 2013 – PowerCLI Best Practices – A Deep Dive session

PowerCLI at VMworld

powercli-logo

Alan Renouf and Luc Dekens led a more advanced PowerCLI session first thing on Thursday morning. There was a good turn up, even after the VMworld Party the night before. This session was of more interest to me, covering off the more advanced features of PowerShell and PowerCLI.

Some of the content I found of interest was:

  • Event filtering with PowerCLI and the handy GUI/utility Alan/Luc have made to help navigate the events objects. (Event objects in the vSphere API start off on a base object “Event” type, with different derivatives that inherit from this base type for different kinds of events). Interesting for me, as I have actually written an iPhone (iOS) application that uses the VMware SDK to filter out and display information about different kinds of events from your vSphere infrastructure.
  • VMware Fling called “Web Commander” – this is a web application which appears to be running off PHP as far as I could tell. It gives end users the ability to easily call various PowerShell / PowerCLI scripts from a UI – which is great for operators, or those that are less comfortable playing with a shell 🙂 I can see a good use case for this in just about any environment. It allows users to call scripts and use textboxes to pass parameters over to your scripts.
  • PowerShell remoting and PSSession creation/disconnection and reconnection to help improve execution times for scripts. Luc showed a nice way to setup a remote machine which can initialise PSSessions, and allow them to be reconnected at a later stage.
  • New vSAN cmdlets coming out with the newer PowerCLI iterations

You can find more information about the session from Luc and Alan’s personal blogs:

Virtu-al.net and LucD.info