The feature I am most interested in is the REST API. After listening to Craig Dalrymplepresent a session at the last Scottish VMUG called Making Your 1st Restful API call to VMware I wanted to try using an API. I had not tried it in my home lab or production at work as I didn’t want to screw anything up, so using Workstation is ideal.

Starting the REST API

The REST API needs to be started from the command line. The file you need to run is located in C:\Program Files (x86)\VMware\VMware Workstation. You can then vmrest.exe --help to see some basic help:

You can see that there is a web based Swagger interface for browsing the API on http:\\127.0.0.1:8697:

Authentication

If you now try to do anything through the API it will not work as we are not authenticated. We need to configure some credentials. This is done using vmrest --config but remember if the API is running you will need to stop it by pressing CTRL+C:

You simply enter a username and password for authentication to the API. Start the REST API again using vmrest.exe. Now in the web interface click the Authorize link in the top right, enter the username and password and then click the Authorize button:

There does not seem to be any visual indication that you are logged in, the only way to check is to do something.

Swagger Interface

The Swagger interface is a great way to try the API. You don’t need to use things like Curl, PowerShell, Postman, etc. you can simply use the web interface to perform API operations. You can see that there are four main sections available with various operations available under them:

There are quite a few operations available in the API. Lets try out a few.

Simple GET Operation

A quick check to see if things are working right is to use the Swagger interface and try a GET operation. GET means reading something, no changes are made – safe!

Browse to VM Management...Show/Hide..GET /vms then click TRY IT OUT! The Response Body shows the two VM’s I have in Workstation:

So in the above screenshot you can see from the interface some useful information. We can see what the response should look like, the HTTP response codes (200 means we were successful), the Curl command, and what we actually want to see, the Response body:

Now we have a list of the VM’s and their IDs we can try something else. Let’s get some VM setting information for a particular VM. To do this use GET /vms/{id}. In the web interface expand VM Management...Show/Hide..GET /vms/{id}. Under the parameter section we need to use one of the ids from above, in this case I will use "id": "RG98SS5QSA90GAP42Q7M4IVAT1VOH2EV".

In the parameters section it is looking for parameter of id. Copy and paste the id of the VM into the field:

One this id is entered click TRY IT OUT!. The Response Body section gives us the details of the VM:

The VM has a single CPU with 64MB of RAM.

Simple PUT Operation

A PUT operation updates something. In this case we want to add a CPU and some memory to a VM. This is under VM Management...Show/Hide..PUT /vms/{id}. We again need to define some details in the Parameters section. The first is the id of the VM like we did above.

Next we need to add some definition of what the VM needs to be changed too. This is in the parameters text box. There is an example shown just to the right:

Again click the TRY IT NOW! button and we get the response:

The VM now has 2 CPUs and double the amount of RAM. We can check using the API again:

DELETE Operation

Finally I want to delete the VM as I am done with it. This is found under VM Management...Show/Hide..DELETE /vms/{id}. There is a warning with DELETE operations. Unlike the GUI there is no confirmation or check you actually want to delete, it just does it. So be aware!

Again we need to define the id of the VM we want to delete then click TRY IT OUT!. This time we get a Response Body and Response Code of:

Not the usual response we have seen above. Usually we get a Response Code of 200, but this time it’s 204. That is 204? Scroll up in the web interface and you see:

So 204 is the VM was deleted. We can confirm using GET /vms:

The VM with the id of RG98SS5QSA90GAP42Q7M4IVAT1VOH2EV is gone.

Wrap Up

When I started with this blog post I had never used an API before, but within an hour I was using the Swagger interface to interface with VMware Workstation. 30 minutes later I was using Postman to do the same. I think using the ‘safety’ of Workstation to get used to the VMware API is a great way of learning how to using the API.

I plan to investigate further as I use Workstation as my lab, so being able to automate operations using the API could help me a great deal. I expect further development of the API as the Tech Preview progresses.

This has been cross posted from my own blog vGemba.net. Go check it out.

Introduction

At a VMUG last year during a presentation by Chris Wahl he recommended that all ops people like me learn a Distributed Version Control System such as GitHub. I use GitHub for my blog and storing some files, and still had not really scratched the surface of it.

Last month GitHub released a tool called GitHub Learning Labthat is basically an app that starts a bot that leads you through some training on the use of GitHub.

Purpose

I have been following the guide for a few iterations now. Back in the early versions there were a lot of settings that could mean the over zealous administrator could have gone in and potentially caused problems. For example in the v5.1 version of the guide there were 172 settings listed over multiple sheets. In the latest version there are 68. A couple of reason for this are the mitigation change has been eradicated due to code changes or the guidance is no longer required because the software is secure by default.

Also included are some common sense ‘best practices’. This goal of secure by default can be seen in the graphs in the blog post from VMware. In vSphere 6.5 there were 24 settings available to harden the deployment. In 6.5 Update 1 there are now 10 due to VMware coding the guidelines into the code. So for that 68 Guidelines 10 are Hardening settings with 58 Non-Hardening (Audit only + Site Specific). Great job VMware! Continue reading →

This has been cross posted from my own blog vGemba.net. Go check it out.

Introduction

A utility that I find very useful for checking my vSphere environment is the amazing tool RVTools developed by Rob de Veij. The utility is a comprehensive tool that shows a lot of information from either a vCenter or ESXi host. Some examples of items it can report on are VMs, Partitions, Resource Pools, Licenses, Datastores, Health, etc. Version 3.10 was recently released so in this post I will run through the installation and usage of RVTools.

Installation

The installer is a simple 6.35MB msi file that can be grabbed from the website. You have to submit your details to get access and you will receive emails from Veeam.

It’s pretty much all live demo and I show how easy it is to get started with Terrform to spin up or clone VM’s. I have posted the code I used on my GitHub. This should be the first of a series on Terraform so watch out for more.

I want thank the vBrownBag team for the opportunity to present. I love the content they produce and to be asked to participate was an amazing opportunity.

This has been cross posted from my own blog vGemba.net. Go check it out!

I recently was able to take the VMware vSphere: Optimize and Scale [V6] – On Demand course from VMware. Why On Demand and not in a Classroom format? Simple – travel time and costs. I was actually looking for the Design & Deploy Fast Track course but annoyingly it seem to be scheduled very infrequently and only in London. With family and work commitments taking a week out to attend was pretty impossible.

So I started looking at the On Demand option. I was scheduled to take the VCAP6-DCV Deploy exam so the O&S On Demand course seemed like a good fit. This was my first time trying an On Demand course instead of Instructor led in class training. The interface is based on the Hands on Labs so if you are familiar with that you will be comfortable using it. The modules covered were: Continue reading →

This has been cross posted from my own blog vGemba.net. Go check it out!

On Thursday 26th October 2017 the second Scotland VMUG of the year happened. An amazing event!

There were 140 registered and I am sure there was well over 100 actually attended. Numbers seem to go from strength to strength and I am sure it’s due to the hard work the leaders do in securing great speakers and content. Three VCDX’s in one day? Yes please.

First up was Duncan Epping on “Evolution of vSAN”. First up he detailed the development of the product – 50x growth predicted from 2010 – 2020. Pretty impressive. We then saw some upcoming features in vSAN. These included:

Live view of disks in the server

LED blink on and off

Simplified cluster creation

Proactive support – vSAN calls home to VMware and GSS can call you

Snapshots will be better

1 – 2 minute VM recovery

The biggest thing mentioned for me was full stack upgrades coming. Using VUM you can perform complete firmware and driver updates of the entire server stack from BIOS up. This will certainly help me push vSAN over another product. Thanks Duncan!

This has been cross posted from my own blog vGemba.net. Go check it out!

Wrap up

We have barely scratched the surface with Terraform. It is a very powerful piece of software that can do much more than building a single VM from a template. I do find the documentation around the vSphere provider to be lacking and there is not much out there on the internet on using it with vSphere, so it’s been a lot of experimentation for me but very enjoyable.

I first started playing with Terraform after watching Nick Colyer’s excellent Pluralsight course Automating AWS and vSphere with Terraform. It gives good demo driven examples similar to what I have shown in this series but goes further by delving into Modules, local provisoners, remote provisioners, etc. If you have Pluralsight access go check it out.

I also found this series of posts from Gruntwork to be excellent. The posts have actually been converted into a book called Terraform: Up & Running so you should go check it out.

This has been cross posted from my own blog vGemba.net. Go check it out!

Introduction

In Part 1 and Part 2 we downloaded, setup, and then created a simple VM using Terraform. Let’s look how to use variables and the files required for this.

Existing Code

Let’s look at the code from Part 2:

provider"vsphere"{user="username@corp.contoso.com"# You need to use this format, not example\usernamepassword="Password1"vsphere_server="vcenter.corp.contoso.com"# If you use self-signed certificatesallow_unverified_ssl=true}resource"vsphere_virtual_machine""webserver"{name="webserver1"vcpu=1memory=2048network_interface{label="VM Network"}disk{datastore="datastore"template="MicroCore-Linux"}}

This has been cross posted from my own blog vGemba.net. Go check it out!

Introduction

In Part 1 of this series we went about installing Terraform, verifying it was working and setting up Visual Studio Code. In this part we will cover some Terraform basics.

Terraform Components

The three Terraform Constructs we are going to look at are:

Providers

Resources

Provisioners

Providers

Providers are the resources or infrastructure we can interact with in Terraform. These can include AWS, Azure, vSphere, DNS, etc. A full list is available on the Terraform website. As you can see it’s a very big list. In this series we will concentrate on the VMware vSphere Provider.

Resources

Resources are the things we are going to use in the provider. In the vSphere realm this can be a Virtual Machine, Networking, Storage, etc.

Provisioners

Terraform uses Provisioners to talk to the back end infrastructure or services like vSphere to create your Resources. They essentially are used to execute scripts to create or destroy resources.

Setup Terraform for vSphere

Open up Visual Studio Code and create a new file called main.tfin the folder C:\Terraform. If you have added C:\Terraform to your Path environment variable save main.tf anywhere you like, but of course the best place for all of your Terrform files is source control…