Tag Archives: vCenter

Let’s talk about SexiGraf

I was introduced to SexiGraf by Eric Bussink during a roundtable at the April London VMUG meeting. The room was divided into those who said “Oh yeah, SexiGraf, it’s awesome” and those, like me, who hadn’t yet discovered it.


SexiGraf is a free community tool that creates some great (you might even say sexy) graphs based on vCenter statistics. Whilst it might not have all the bells and whistles of the big commercial monitoring solutions it does provide a neat, easy to use, web-based interface to get at those important headline figures and how they’ve changed over time.

Screenshot_20170620-092020The small footprint  (2vCPU, 2GB) makes it ideal for the homelab, but there’s also scope for keying into larger production environments to get a quick look at the state of your environment, event from a mobile device when you’re at the airport or in a meeting.

Installation is straightforward and well documented- SexiGraf deploys via an OVF template to the Virtual Infrastructure and connection to vCenter just requires a read-only vSphere credential to be provided. Updates are quick and easy too as a simple patch package can be uploaded via the web admin interface and the server patched in minutes without any loss of history.

Having run this myself for just a couple of months I can already see the benefits both from a capacity planning point of view but also when troubleshooting- “is this host using resources differently to others?” or “is the cluster usage different to normal?”.

As well as the vSphere statistics, SexiGraf is continually expanding it’s range. VMware vSAN, Windows, and FreeNAS connectivity is all offered and HP C7000 and S.M.A.R.T counters are under development.

If you haven’t yet discovered it, I’d recommend having a look. Downloads and full details are here- http://www.sexigraf.fr/

Using PowerShell and REST-API to create a VM in vCenter

VMware vSphere 6.5 comes with a RESTful API implementation and there’s some great documentation out there- starting with the API Explorer (http://my.vcenter.name/apiexplorer ). Here’s a quick piece on how to use this API to create a VM from the PowerShell command line. This is intentionally not using PowerCLI,  just the native PowerShell cmdlets- partly as a REST learning experience for me, and partly so the API code can be transferred to another language at a later date.

Step 1- Authenticate with the Server.

This step is well documented by Chris Wahl. I’ve borrowed some of his code here, and accompanied it with a section to get around the lack of trusted certificates on my homelab. is the IP of my VCSA, so if you’re reusing this anywhere remember to replace that hard coded value where it appears.

#Step 1- Authenticate with the Server
#Ignore Server Certs- This is on my not-very-well-certified home lab.
if (-not ([System.Management.Automation.PSTypeName]'ServerCertificateValidationCallback').Type)
using System;
using System.Net;
using System.Net.Security;
using System.Security.Cryptography.X509Certificates;
public class ServerCertificateValidationCallback
public static void Ignore()
if(ServicePointManager.ServerCertificateValidationCallback ==null)
ServicePointManager.ServerCertificateValidationCallback +=
Object obj,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors errors
return true;
Add-Type $certCallback

#Get Some Credentials and Determine Authorisation Methods
$Credential = Get-Credential
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Credential.UserName+':'+$Credential.GetNetworkCredential().Password))
$head = @{
'Authorization' = "Basic $auth"

#Authenticate against vCenter
$r = Invoke-WebRequest -Uri -Method Post -Headers $head
$token = (ConvertFrom-Json $r.Content).value
$session = @{'vmware-api-session-id' = $token}

Now we have the Session ($session) we can test this by retrieving a list of VMs.

#Get a List of VMs
$r1 = Invoke-WebRequest -Uri -Method Get -Headers $session
$vms = (ConvertFrom-Json $r1.Content).value

Step 2- Construct the JSON specification

To create a new VM we need to provide a minimal spec for the machine, in JSON format. We need to tell it the intended Guest OS, what datastore is going to hold the VM, and where the VM will be placed in the resource/folder structure. To complete this we need to establish what options are available- just sticking in the display names of a datastore or folder from the Web Client will not work and will likely generate 404 responses to the API call.

To find these names we can use the API, API explorer gives us the following urls

Datastore:       /rest/vcenter/datastore
Folder:              /rest/vcenter/folder
Resource Pool: /rest/vcenter/resource-pool

So we can use PowerShell to retrieve a list of Datastores using this line of code

(Invoke-RestMethod -Uri -Method Get -Headers $session ).value

which will produce a list of datastores, each looking something like this:

datastore  : datastore-11
name       : Datastore2
type       : VMFS
free_space : 100553195520
capacity   : 249913409536

From this example we want the value of the “datastore” field, e.g “datastore-11”.

Once we have this information we can combine it all to create a JSON spec file. My example looks like this:

"spec": {
"guest_OS": "RHEL_7_64",
"placement" : {
"datastore": "datastore-11",
"folder": "group-v224",
"resource_pool": "resgroup-182"

Step 3- Create the Virtual Machine.

Now we’ve done all this prep work, creating a Virtual Machine comes down to a single line of PowerShell pointing at the data.txt file containing the JSON code from Step 2.

Invoke-WebRequest -Uri -Method Post -Headers $session -ContentType "application/json" -Body (Get-Content data.txt)

Example Output:

StatusCode        : 200
StatusDescription : OK
Content           : {"value":"vm-462"}
RawContent        : HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/json
Date: Mon, 27 Mar 2017 09:41:34 GMT

Forms             : {}
Headers           : {[Transfer-Encoding, chunked], [Content-Type, application/json], [Date, Mon, 27 Mar 2017 09:41:34 GMT]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 18

The VM is created and we can check this from the vSphere Client:

2017-03-27 (10)

So, to summarise. Native PowerShell, with a little bit of JSON, can be used to communicate with the vSphere APIs and create new Virtual Machines. Depending on your use case there may be better ways of implementing automation processes through this API (PowerCLI is a good start) but if you want to drop to the raw RESTful API, possibly as a stepping stone to a larger project, PowerShell provides a handy method to get started down that path.

Rolling back a failed VCSA HA deployment

The deployment of High Availability in the vCenter Server Appliance 6.5 is very slick and there’s a great step-by-step walkthrough of how to implement it. However, sometimes things go wrong – in my case a misconfiguration in the underlying network meant that the hosts I was trying to deploy to couldn’t reach each other on the new HA network.

The good news is the smooth Installation process is accompanied by a smooth uninstaller when things have gone wrong. It’s nice to see that this part of the application lifecycle process hasn’t been ignored by the development team at VMware. With the right planning and a bit of luck, you’ll never have to see this yourself- but here’s some example screenshots.

The install has failed, the wizard was unable to configure HA, and we are left with a situation looking like this:


The vSphere Web Client is telling me “vCenter HA has an invalid configuration. Click the remove button to destroy the current vCenter HA cluster configuration”. And it is really as simple as that, clicking Remove starts the process- this doesn’t destroy your vCenter environment- just the failed HA attempt – and vCenter reverts back to the model it was using beforehand. We get a nice clear explanation of what is going to be done, details of what manual steps may be necessary, and an option to change our mind.


The task proceeds like any other vCenter operation, showing as Completed in the Recent Tasks bar- in my homelab this removal task took just 11 seconds.


Once done it was just a case of powering down and removing the defunct Passive and Witness VMs, fixing the pre-existing fault that had caused the error in the first place, and then running the install again.It should end up looking something like this:image

It’s always good to see that development effort has been put into helping the user when something unexpected has occurred and this is a good example of that.

Auto Power On and VCSA Upgrades

VCSA Upgrade

VCSA Upgrade via the Appliance Installer

The vCenter Server Appliance (VCSA) upgrade from 6.0 to 6.5 is a slick, well managed, process. The installer deploys a new appliance, transfers all the settings from the old one (including IP address and identity) and then powers the old appliance VM off. This provides a neat roll-back option if something has gone wrong- you just power down the new appliance and turn the old one back on.

In upgrading my homelab I came across a small gotcha in this however. If you have your old VCSA VM set to auto power on when the host is then the next time you reboot that host (for example when you’ve done a Hypervisor upgrade) the old VCSA will turn on. You could now, like me, be in the situation where two VCSAs are running at the same time and sharing an IP. In a larger environment this is unlikely to happen- the host-based VM Startup/Shutdown feature is largely replaced by HA and DRS rules – but in a smaller setup this is a common practise to ensure that the vCenter comes up when the lab is switched on.

VM Startup and Shutdown

Automatic VM Startup and Shutdown with 2 vCenters

The solution is to switch the Startup behaviour to manual for the old VCSA, and just to make sure disable the virtual NIC on that old VM. Of course once you are happy with the upgrade the old Virtual Machine can be archived/deleted altogether.

Support Bundle taking up log file space on VCSA

The log file disk was nearly full on a vCenter Server Appliance instance, showing a warning message in the vCenter console and the VAMI (Login to https://vCenterHostName:5480). After a bit of investigation (and I’d recommend looking at this article by Brandon Lee and Knowledge Base 2143565 ) I found an old Support Bundle was taking up 2GB of the log disk unnecessarily and tripping the alert threshold.

SSH into the VCSA using the username root (see KB2143565) and navigate to the folder


And look for files named “*_vmsupport.tgz“, check the timestamp on these files and remove any old ones that are no longer required.
Hopefully the warning should clear and the health status should return to green in the vSphere Appliance Management Interface
Healthy VCSA