Home > Blogs > VMware {code} > Monthly Archives: February 2017

Monthly Archives: February 2017

Containers and Persistent Storage Meetup: 02/15 Event Follow-Up

A clear trend that is emerging in the future of stateful containers is the option to run the entire storage stack as part of the container orchestration framework. Minio and Quartermaster are two offerings that help achieve a fully containerized storage stack.

Talk 1: Object Storage in a Cloud Native Container Environment

This talk looked at the modern application stack whereby a cloud native application is split into both stateless and stateful containers. Whereas the (many) stateless containers allow for easy and dynamic scalability, the stateful containers manage the application state. Depending on the nature of the persistent data different technologies are best suited to address them. For large data/blobs object storage has emerged as the preferred way to handle these in a scalable manner.

About the presenter: Frank Wessels is an entrepreneur in the IT industry. He started in 1993 in ISG Technologies as a developer for medical systems in Torronto, Canada, but since 1992, he participated as a co-founder and chief architect in a business aimed at the development of a PACS system for radiologists. Frank remained in the healthcare industry until 2013 as the founder of another company called 3mensio Medical Imaging that focused on doing 3D visualisation using GPU technology. Since 2014 he switched to Cloud Computing in co-founding a company that built a new product for transferring content over the internet. Lately he has focused on Golang as well as gotten involved in object storage via a new startup company called Minio (@minio).

Talk 2: Project Quartermaster

The deployment and management of distributed storage systems is not only complicated, but also quite different across different storage systems. Although some distributed storage systems have their own deployment tools, they are based on a bare metal or virtual machine model and do not integrate easily with Kubernetes. This talk introduced Quartermaster, a framework for managing containerized storage systems like Ceph, GlusterFS, NFS-Ganesha, Rook and others on top of Kubernetes. Quartermaster enables the deployment, installation, and integration of these type of storage systems onto a Kubernetes cluster. Quartermaster abstracts this complexity and presents the client with a simple storage deployment model which is fully integrated with Kubernetes. By simplifying the deployment of storage systems, Quartermaster makes it possible to easily and reliably deploy, upgrade, and get status of a desired storage system in a Kubernetes cluster

About the presenter: Luis Pabón (@_lpabon_) is a software engineer at CoreOS. Prior to joining CoreOS in November of 2016, he worked at Red Hat Storage, NetApp Advanced Technology Group, and at EMC on various storage products.

The recording of the livestream is archived on the VMware Technology Network Facebook page. Talk 1 starts right at the beginning. Talk 2 starts around the [00:50:30] mark.

* * *

To find out about future events, follow @vmwarecode on Twitter or join the Containers and Persistent Storage Meetup. To continue the conversation, join VMware {code}: https://code.vmware.com/join

Getting Started with the vSphere Automation SDK for REST – Part 2

We’re continuing the “Getting Started” series focusing on the vSphere Automation SDK for REST! In this part of the series, we’ll be switching gears and looking at the JavaScript (JS) examples which were included in the SDK download.

JS samples were included in the REST SDK to provide an easy example of how to call the vSphere REST API using a common and easy web based language.

To check out the first part in the series where we cover accessing the documentation and using Postman, see the following link: https://blogs.vmware.com/code/2017/02/02/getting-started-vsphere-automation-sdk-rest/

Preparing The Environment

If you haven’t already done any JS work in your current environment, there are a couple preparation steps that are required to get started. While there are many ways to get started with JS, my personal preference is outlined below.

Download NodeJS for your preferred OS and install it, ensuring the “NPM Package Manager” is also installed: https://nodejs.org/en/download/

NodeJS Installation

The reasons I’m using NodeJS and the associated NPM is because NodeJS will allow us to execute JS directly from the command line. NPM (Node Package Manager) will be used to install any of the package dependencies we’ll be needing, as documented in the project.json file.

Lastly, download and install Visual Studio Code which will be used as the IDE (or Integrated Development Environment): https://code.visualstudio.com/Download

Visual Studio Code Installation

However, please note, an IDE is not required to run these samples.

First Steps

We have our environment setup, the vSphere Automation SDK for REST is already downloaded (from Part 1), and we’re ready to move on. Let’s begin by examining the contents of the JS folder within the unzipped SDK directory: VMware-vSphere-Automation-SDK-REST-6.5.0\client\samples\javascript\vcenter

We’ll start by going through the README. There’s a couple important parts in there with regards to getting started, plus it’s always good to get a better understanding of what’s going on with some of these samples.

The beginning portion of the README illustrates a need to download and install some Node modules. These modules are dependencies of the samples and are sourced from the packages.json file in the vcenter directory. We can do this with the following commands at a prompt:

Installation of Dependancies via NPM

The bottom portion of the README provides a list of all the samples that have been included. Which are as follows:

  • vm-details
  • vm-create-defaults
  • vm-create-details
  • vm-power-on
  • vm-power-off
  • host-add
  • host-remove
  • host-connect
  • host-disconnect

The last of the first steps is to fill in some of the parameters included as part of the settings.js file. These parameters include some information like which REST endpoint we’re connecting to and which what credentials we’re using to authenticate with. If you recall the Environmental Variables we configured in Part One of this blog series, these parameters work very similarly to those. One item to keep in mind while filling in these parameters is related to the “Host” information, the endpoint will need to have to prepend “https://” to the value. See the example below for a bit more information:
Basic Config for Settings File

VM Samples

There are several VM examples that are included with this SDK. The easiest and most straight forward of the examples is retrieving details of the VMs associated with the API endpoint by using the vm-details sample. It’s executed by running: npm run vm-details

Output from npm run vm-details

Another sample is about how to create a VM using defaults. This sample requires the host1 and datastore parameters to be completed within the settings.js file.

VM Creation Config for Settings File

If you remember from part 1 of this series, the default settings are made based upon the Guest OS type. This sample creates a VM based on it being a “RHEL_7_64” Guest OS type, which can be seen on line 86 of the create_vm_with_defaults.js script. Another parameter which is set as part of the script is which folder the VM is created in. Referencing line 72 of the same script, we can see it searching for the “Discovered Virtual Machine” folder.

The sample can then be run with the following command: npm run vm-create-defaults

Output of: npm run vm-create-defaults

We can see the VM was created with a hardware ID of vm-96. Let’s go back to our first sample and verify that the VM was indeed created.

Output from npm run vm-details

If we want to perform some actions to that newly created VM, there are a couple samples we can use. However, before we do that, we will need to update the settings.js file to indicate the name of the VM we’re targeting.

VM Actions Config for Settings File

The two samples we have access to which can modify the VM are power actions, so powering on or off the system. We can perform the power on action with the following command: npm run vm-power-on

Output from npm run vm_power_on

We can see in the above example that the proper VM is found, as referenced by the hardware ID of vm-96. We can then see the status code of 200 meaning the request was successfully received.

Powering off the VM is just as easy as powering it on, and can performed with the following command: npm run vm-power-off

Host Samples

We’re going to switch gears a bit and take a look at some of the host based samples. Since this is an existing environment, I’ll be showing how to disconnect and reconnect a host. Before running the commands, we’ll need to update our settings.js file again to reference the host we’re working with. The host will be designated via the host1 parameter.

Host Actions Config for Settings File

If you happen to be adding a host, the hostUsername and hostPassword parameters should be completed as well. They are not needed for the examples below.

In order to disconnect a host, we’ll run the following command: npm run host-disconnect

Output from npm run host-disconnect

If we want to reconnect that host, we run the following command: npm run host-connect

Output from npm run host-connect


When you start creating additional JS scripts, some of the work has already been done for you. Check out the resources directory, it will have multiple individual top level object based scripts that have some of the functions already created. If the function isn’t already created, the vSphere Automation API is really easy to work with so you can easily add your own to the SDK’s samples.

Getting Started with the vSphere Automation SDK for REST

vSphere 6.5 introduced a big update to its newest API service, which is known as the vSphere Automation API. This API is a big step forward in the process of simplifying and modernizing our APIs. This service also allows us to introduce several new SDKs for the following programming languages: Java, Python, .NET, Perl, Ruby, and REST. This blog will take a look at the REST SDK and how to easily get started using it.

For more information about what was introduced with the vSphere Automation APIs, check out the associated What’s New blog post.

Accessing the SDK

First things first, we need to gain access to the vSphere Automation SDK for REST from VMware’s GitHub repository: https://github.com/vmware/vsphere-automation-sdk-rest Make sure to read through the README, noting that we’ll be able to view and use these resources, as well as contribute back to the following items:

The easiest method is now to either download or clone the repository.

Downloading can be done as follows:

  1. Click on the green “Clone or Download” button and then click “Download ZIP”
  2. Once downloaded, extract the zip file to the location of your choosing
  3. At this point, you will now have a local copy of the repository

Cloning can be done as follows by CLI:

  1. Click on the green “Clone or Download” button and then copy the clone URL
  2. Within Terminal, change to the appropriate directory, and enter the following command: git clone [Copied URL]
  3. Once the tasks complete, you will now have a local copy of the repository

git CLI Clone Process

Cloning can also be done through the GitHub Desktop client as follows:

  1. Click on the green “Clone or Download” button and then click “Open in Desktop”
  2. Within the newly opened “Clone As” window, select the appropriate directory and name, then select “Clone”

GitHub Desktop Clone Process


The documentation for this SDK has improved so much it deserves its own section. The documentation is just clean and straight forward. Looking at it from a high level, you can browse each API and see the sections of what the underlying operations cover. Each of the operations list the method, URL, and a brief description of what it’s used for. To receive some more in-depth information, click on the operation’s method. Here you’ll see all the information needed in order to perform the request including the request parameters, response codes, JSON and XML response representations, followed by a table of what those response types mean, and it also covers the error codes.

vSphere Automation Documentation Example

Install Postman

One of the most convenient ways to get started using this SDK is with the Postman application. If you’ve never heard of Postman, it is a simple and free REST API client. It can be installed on Windows, OSX, and Linux (although this is currently a beta install). While there is a Chrome app, we have found the best experience is with the full client application.

Postman can be downloaded at the following link: https://www.getpostman.com/apps

Initial Setup

At this point we have the SDK downloaded and the recommended client installed, so let’s get Postman setup with everything needed to work with the SDK.

First, start by importing the collections which were downloaded as part of the SDK. This can be done by clicking the “Import” button. On the new screen, with “Import File” selected, click the orange “Choose Files” button, browse to the location where you unzipped the SDK and then navigate to: client\samples\postman. Select the two JSON files in the directory titled:

  • vSphere-Automation-Rest-API-Resources.postman.json
  • vSphere-Automation-Rest-API-Samples.postman.json

vSphere Automation Postman Collection Import

We’ll now notice two new collections which are named quite similarly to the files imported. The vSphere Automation REST Resources collection is a number of requests, grouped in folders by their object level, that can be performed against a vSphere environment. The vSphere Automation REST Samples is a couple groups of requests which can be combined to perform a normal task. Some of the examples include ESXi host connection and disconnection, VM creation, and VM power actions.

Last part of setup comes down to configuring some environmental variables. As you begin browsing through the requests, you’ll start noticing some double curly brackets that may look like this: {{vc}} This is what’s known as an environmental variable within Postman, and vc will be used to refer to the vCenter Server. There’s only a couple environmental variables which need to be set in order to begin: vc, user, password. Those are fairly self-explanatory, so let’s set them up in Postman.

To begin creating environmental variables, head towards the gear icon in the top right hand side and click on it. This is where environments are managed. Add a new environment by clicking on the orange “Add” button. Give the environment a name, then enter in those three items mentioned above and valid values for your environment. Click the orange “Add” button again to complete the creation, and click on the “X” to the right of “Manage Environments” to close the window.

vSphere Automation Postman Environmental Variables

Getting Authenticated

As with all vSphere environments, the first step is to authenticate. Expand the vSphere Automation REST Resources collection, expand the Authentication folder, and select Login.

vSphere Automation Postman Authentication

We can gather a bit of information about the request at this point. We’ll be doing a Post method to the vCenter’s URL of /rest/com/cmware/cis/session with a basic authentication type and sourcing the username and password from our environmental variables. Before making the request, make sure to select the environment that was just created by selecting it via dropdown box next to the gear icon on the top right hand side.

vSphere Automation Postman Session Info

NOTE: If you have any issues, you may need to turn off SSL certificate verification in the Settings (File > Settings > General tab > SSL certificate verification, turn off, restart Postman)

Environment Discovery

We’re now authenticated to the vCenter’s API endpoint, so we can start exploring some other areas within the vSphere Automation REST Resources section. Let’s do some environmental discovery while we’re still exploring the SDK.

To get a list of the hosts available by this vCenter’s API endpoint, expand the Hosts folder and select List. Here we can see the request uses a Get method to the vCenter’s URL of /rest/vcenter/host. Clicking “Send” will give us a list of the hosts available as well as some basic information such as the host ID, name, connection state, and power state.

vSphere Automation Postman Host List

To get a list of the datastores available by this vCenter’s API endpoint, expand the Datastores folder and select List. This request is very similar to the last request, except it points to the vCenter’s URL of /rest/vcenter/datastore. Clicking “Send” will give us a list of the datastores available as well as their datastore ID, name, type, free space and capacity.

vSphere Automation Postman Datastore List

To get a list of the VMs available by this vCenter’s API endpoint, expand the VM folder and select List. At this point, hopefully you can figure out what the request is going to look like and a rough guess at what information is going to be pulled back.

vSphere Automation Postman VM List

We’ve got the basics down now, how about getting into some additional detail on a VM. In the VM folder, select the Details. In the URL, we’re just appending the VM’s ID to the end of the prior call. The example includes ‘vm-22’ which can be modified to a VM ID as identified in the prior request. Clicking on “Send” retrieves a ton of information back about the configuration settings for that VM including CPU information, NICs, boot configuration, and so forth.

vSphere Automation Postman VM Details

VM Creation

Last example, creating a VM. We’ve just seen all of the configuration settings for a VM, however we don’t need to have all of those to create a VM with this SDK. The API endpoint has the capability of setting those options automatically per best practices and VMware’s guidance. These decisions are all based on the guest OS type.

We’ll start by selecting the “Create with defaults” option. Notice the familiar URL, however we’re performing a Post method on it this time. Switching over to the “Body” section, we can see some items have already been filled in for us like Guest OS type, datastore, folder, and resource pool. These are the basics in order to perform this request.

Once those options have been filled in with valid values for your environment, click the blue “Send” button to create the VM.

vSphere Automation Postman VM Creation

You should see a response that resembles a VM ID. Run the VM Details request again, only this time substituting the new VM’s ID in the request URL. Scrolling through the response’s body, take note of many of the areas which were populated automatically. Things like memory, disk size, SCSI controller, even the name were all populated automatically.

vSphere Automation Postman VM Details

If you’ve done this through the API before, this is a tremendous improvement! If there are additional things you’d like to specify, that’s possible as well. If you want to populate the settings for all of those items, that too is possible. It is all about the user’s choice.

Wrapping Up

We just scratched the surface on what’s possible with this SDK and Postman. There’s many more areas to check out and explore. There’s also the samples collection to take a look at too. Be on the lookout for part two, where we take a look through the javascript portion of this SDK!