Home > Blogs > VMware {code} > Tag Archives: vAPI

Tag Archives: vAPI

Getting Started with the vSphere Automation SDK for Ruby

There has been another exciting open-sourced release in the vSphere Automation SDK lineup. This time, it is the vSphere Automation SDK for Ruby!

That means it’s time for another blog post in our series on ‘Getting Started with the vSphere Automation SDKs’. The posts already available in the series so far are as follows:

We’ll be taking a look at how to easily get started with this SDK on Mac OS. Before diving in, there are a couple prerequisites we’ll need to download and install.

Note: If you’re using this SDK on any other OS, check out the ‘Quick Start Guide‘ section of the GitHub repository for guidance.

Prerequisites

The first thing we’ll want to do before getting started with this SDK is to clone the repo to the local system. We can do that with the following command:
git clone https://github.com/vmware/vsphere-automation-sdk-ruby.git

Cloning the SDK for Ruby Repository

We will then need Ruby to be at version 2.3.1 or better. On this particular system, which is currently running Mac OS Sierra (10.12), we see that it’s currently running Ruby 2.0.0.

Checking the version of Ruby currently installed

In order to obtain the newer version of Ruby, we will need to install the package manager, Homebrew. If you don’t have it already, it can be easily downloaded and installed with the following command:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Installing Homebrew

Next, we will install the latest version of Ruby available. We will do this, through Homebrew, with the following command:
brew install ruby

Installing the latest version of Ruby via HomeBrew

This SDK also has a couple dependencies which will also need to be installed. These dependencies are called out in the Gem specification file which is located in the root of our cloned repo directory. The Gem spec file is named: vsphere-automation-sdk-ruby.gemspec

In order to easily install all of these dependencies, we will use Bundler. Bundler is used to manage the required gems and which versions of those gems are required. We can install bundler with the following command:
gem install bundler

Installing the Ruby Gem for Bundler

Lastly, we will need to build and then install our Gem. To perform the build, switch to the directory where the vsphere-automation-sdk-ruby.gemspec file is located and run the following command:
gem build vsphere-automation-sdk-ruby.gemspec

Building the Ruby Gem for the SDK

Once complete, we will have the Gem that we’ll need to then install. We can take the Gem filename and run the following command:
gem install vsphere-automation-sdk-2.5.0.gem

Installing the Gem for the SDK

We are now all setup to start using the vSphere Automation SDK for Ruby!

One quick item to note, the SDK’s documentation is available locally as part of the cloned repository.
The API docs are available in the following location: /docs/apidocs/vsphereautomation-bindings
The Samples docs are available in the following location: /docs/apidocs/vsphereautomation-samples

Running Samples

There are a couple samples which are included with the SDK, they are:

  • Connection: Sample framework to successfully connect to the vSphere Automation API endpoint and retrieve the SAML token
  • Tagging: Create vSphere Tag Category and associated tags
  • List_VMs: Create a list of available VMs containing the VM Name, Power State, Number of CPUs, and Memory Size in Megabytes

These are made available through the launcher.rb file in the following directory within the repo: /client/samples/bin/launcher.rb

Included Samples

As additional samples are created and/or contributed from the community (such as the ‘list_vms’ sample was), this will be the place to look for them.

To call each of these samples, we’ll need to call the following file: /client/samples/bin/run_sample

If we run that command alone, it will show an example populated command and the available samples matched to their configuration files within the repo.

Example output from the run_sample command

Each of these samples also offer a help functionality using either the ‘–help’ or ‘-h’ parameter which will display additional parameters for the given sample.

Taking a look at the connection sample, we can run the following command to understand what the sample is looking for in terms of parameters: bin/run_sample connection –help

Displaying the help output for one of the sample workflows

Now, we can create the full command in order to obtain a SAML token and login to the vSphere Automation API endpoint. The example we’ll use is as follows:
bin/run_sample connection -l vcsa01.corp.local -u 'administrator@vsphere.local' -p 'VMware1!' –k

Example of connecting to a vSphere API Endpoint

Moving to the tagging sample, we have the ability to create tag categories and their associated tags. Running an example will look like the following:
bin/run_sample tagging -l vcsa01.corp.local -u 'administrator@vsphere.local' -p 'VMware1!' -k --category-name 'SDKTagCategory' --tag-name 'SDKTag'

Example of creating a Tag Category and associated Tag

Lastly, we’ll use the ‘list_vms’ sample to create a list of the VMs available in our environment. We can do this with the following command:
bin/run_sample list_vms -l vcsa01.corp.local -u 'administrator@vsphere.local' -p 'VMware1!' –k

Example of listing the VMs available in an environment

Summary

This post shows you how to easily get started with the vSphere Automation SDK for Ruby. It takes you through the setup of an entire environment, as well as running some of the individual samples. You can then take whichever is most relevant to you and apply to your environment or, pull parts of this code out and use it to automate or integrate as needed.

With our SDK now being open sourced, we are intent on making sure these samples are of a high quality. If you notice areas of improvement, or come up with some new samples, please feel free to raise issues or pull requests on our GitHub repository.

Getting Started with the vSphere Automation SDK for Python

We’ve been looking at how to get started using the new vSphere Automation SDKs. In the last couple parts of the series we looked at the SDK for REST, which included Postman REST client samples, as well as some JavaScript samples. This time, we’ll be looking at the vSphere Automation SDK for Python!

Prerequisites

There are a handful of ways to install and setup Python on your workstation, I will be walking through a high level configuration for my Mac.

First things first, clone the vSphere Automation SDK for Python from the VMware GitHub repository located here.

Cloning the Python SDK repo

After that’s complete, we’ll need to install the Python prerequisites. These include the GNU Complier Collection (GCC), a C compiler, and HomeBrew, a package management system.

GCC can be installed in multiple ways, but I’ve found it’s easiest to obtain it by installing the Xcode Command Line Tools. This can be done with the following command, then following the prompts:
xcode-select --install

XCode Installation

Next, we’ll need to install the package manager, Homebrew. It can be easily downloaded and installed with the following command: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Homebrew Installation

Finally, we’ll install Python in the recommended version of 3.6. It’s worth noting here that Mac OS X comes with a version of Python already installed. However, it is generally an older version (normally, Python 2.7) and is used for some system related tasks. Due to that, it is best not to modify that version or the defaults.

Utilizing our package manager, we’ll install Python 3.6 with the following command:
brew install python3

Python 3.6 Installation

It’s also recommended to isolate your development environments from each other so, we’ll setup a virtual environment and jump into it. We can do that with the following commands:
python3 -m venv SDKDemo
source SDKDemo/bin/activate

Creating a virtual development environment

Lastly, we’ll install the SDK requirements. They’re listed within the root of the SDK folder in the file labeled: requirements.txt. After checking out which requirements are necessary, we’ll install those requirements by way of the following command:
pip3 install -r requirements.txt

Requirement Installation

One other item worth mentioning is an IDE. This will make editing, running and debugging the code a lot easier to deal with. I’ll be using PyCharm, which is available here.

Running Sample Setup Script

To really show off the capabilities of the SDK, there’s a sample script which takes an un-configured vSphere environment and performs all of those normal configuration steps. The environment requirements to run the script are as follows:

  • 1 vCenter Server
  • 2 ESXi Hosts
  • 1 NFS Datastore (minimum of 3GB free)

We’ll first need to open up the testbed.py file and populate lines 17 through 29 as follows:

Modification of the Testbed File

We’re now ready to set the environment up with the sample script! However, before running the script we should take a look at what it’s doing. The script is available in the SDK directory at: /bin/run_sample.sh The goal of the script is to do the following actions:

  • Create 2 Datacenters
  • Create a Cluster
  • Create Test Folders for VM Storage
  • Attach the Hosts
  • Create a Distributed Switch
  • Create a Distributed PortGroup
  • Attach the NFS Datastore (if Selected) to the hosts
  • Copy the Photon OS ISO image downloaded from VMware’s bintray server to the Datastore
  • Create directories to add sample ports

One note before running the script, the ISO image being downloaded is roughly 200MB and could take a while depending on your bandwidth. My tests ranged anywhere between 30 seconds and 5 minutes.

The sample script can be run with the following command:
./run_sample.sh ../samples/vsphere/vcenter/setup/main.py –sv

Configuring an environment with the main.py file

Create a VM with Defaults

Now that our environment is setup, let’s take a look at adding a VM to this environment. The easiest way is to create a default VM. This action means the API takes care of all the configuration settings based on the Guest OS version. There are some prerequisites that are required for placement such as desired datacenter, VM folder, and datastore. These are all referenced from the testbed.py configuration file we referenced in the first example.

Updating the Testbed File for VM Tasks

The VM can then be created with the following command:
./run_sample.sh ../samples/vsphere/vcenter/vm/create/create_default_vm.py –v

Default VM Creation Sample

Notice in the above example how even though we didn’t populate all of the settings, the VM received required items like a CPU, a disk, and so forth.

To verify the VM does indeed exist, we can obtain a list of VMs with the following command:
./run_sample.sh ../samples/vsphere/vcenter/vm/list_vms.py –v

List VMs Sample

VM Power Actions

The next logical step after creating a VM is to power it on. There’s a sample within the vm folder named power.py, which shows off all of the power actions. This file references the ‘VM_NAME_DEFAULT’ input from the testbed.py file.

When running the command as is, the VM will be put through the following power states:

  • Obtain current power state
  • Power Off (NOTE: Only if the VM is currently powered on)
  • Power On
  • Suspend the VM
  • Resume the VM
  • Reset the VM

The command can be run with the following:
./run_sample.sh ../samples/vsphere/vcenter/vm/power.py –v

VM Power State Sample

Summary

This post shows you how to easily get started with the vSphere Automation SDK for Python. It takes you through the setup of an entire environment, as well as using the individual samples. You can then take whichever is most relevant to you and apply to your environment or, pull parts of this code out and use it to automate or integrate as needed.

With our SDK now being open sourced, we are intent on making sure these samples are of a high quality. If you notice areas of improvement, or come up with some new samples, please feel free to raise issues or pull requests on our GitHub repository.

vSphere Automation SDKs – Open Sourced!

It’s an exciting time! We have started the process of open sourcing our vSphere Automation SDKs! The first ones to be released are the Software Development Kits (SDKs) for REST and Python: https://vmware.github.io/vsphere-automation-sdk

Alan Renouf, the Product Line Manager for the vSphere Automation SDKs (among other things), has a great post detailing the significance of it over on the VMware Open Source blog: https://blogs.vmware.com/opensource/2017/03/09/integration-vmware-vsphere-using-new-open-sourced-software-development-kits

vSphere Automation SDK Open Source Logo

What to Expect

Open sourcing these SDKs are going to have a considerable impact on how they’re consumed, so what should you be expecting with these changes?

The biggest impact: these SDKs are available on GitHub, with no authentication required. Users can clone or download the repository locally or even fork it to their own GitHub account. The use of modern Github integrated tools can ensure these SDKs fit well into your development tooling and procedures.

The first part leads to the next big impact: the frequency of updates. These SDKs being on GitHub allow us to release updates, bug fixes, and other corrections on a much quicker basis!

One of the other big impacts this change is going to have is on contributions. We are actively seeking contributions! Regardless of whether it’s a new sample, an update, or even a request, we want to hear from you! We are dedicated in making these samples relevant to you and making your development experience easier and better than ever before. Please, let us know how we can help you do this.

Getting Started

There are a lot of ways to get started with this new method of access. The easiest way is to check each repo’s README and follow the instructions there.

However, let’s walk through an example. One of the simplest ways, downloading it directly from the SDK’s repo.

Using the vSphere Automation SDK for Python:
Repository Link: https://github.com/vmware/vsphere-automation-sdk-python

Click the “Clone or Download” button, selecting the “Download ZIP” option.
Find the downloaded zip file and expand it.

Downloading the vSphere Automation SDK for Python

Contributions

If you happen to hit an issue when using one of the SDKs in your environment, or if you’re doing something that doesn’t already exist as a sample, there’s a good chance someone else could benefit from that input. Therefore, we highly encourage contributions to these SDKs.

Each SDK will have the contribution and/or issue process documented in the README. However, I’ll provide an overview of both the sample and issue submission process.

Sample Submission:

  • Include information as part of the resource or folder’s README:
    • Author Name (basic contact info)
    • Date
    • Description (high level description)
    • Known Limitations or Dependencies
    • vSphere Version/s Developed and/or Tested (suggested, but not mandatory)
    • SDK Version/s Developed and/or Tested (suggested, but not mandatory)
    • Language Version/s Developed and/or Tested (suggested, but not mandatory)

Contribution Process:

  1. Follow the GitHub process
  2. Use one branch per sample or change-set
  3. Use one commit and pull request per sample
  4. Post the sample output along with the pull request
  5. If including a license with the sample, use the project license

Issue Submission: Each repo has their own “Issues” tab and should be used to submit any issues or requests

  1. Once on the “Issues” tab, click the green “New issue” button
  2. Provide a title and as much detail as possible in the comment section

vSphere Automation Issue Submission

If you’re submitting a sample, we also recommend adding them to the VMware Code Sample Exchange!

Wrap-Up

This transition to open source is a big step for us at VMware. This is also just one of the first steps of many which are focused on helping to enable developers and automation focused admins!

Keep an eye on this blog, the Open Source blog, and especially the vSphere Automation SDK page for all the exciting updates and additional news.

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

Wrap-Up

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

Documentation

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!