Jenkins Plugin for vRA 7!

vrajenkins

Introducing the Jenkins Plugin for vRA 7!!!

So let’s get the first question that comes to mind out of the way…

Question:  Does the Jenkins plugin for vRA 7.0 compete with vRealize Code Stream?

Answer:  Absolutely not.  The Jenkins plugin for vRA 7 is targeted at teams that need basic integration with Jenkins and vRA.  The Jenkins plugin does not provide release management or release pipeline features. Teams requiring release management and release pipeline features should evaluate vRealize Code Stream to gain visibility and control over their release process.

Now that we’ve established the scope of the Jenkins plugin versus the rich features of vRealize Code Stream, lets cover a bit of history with vRA and Jenkins.  Prior to vRA 7 and the Jenkins plugin you only had two options for integrating Jenkins with vRA.

  1.  CloudClient:  The CloudClient for vRA can be used as an integration with Jenkins and vRA.   While the cloud client for vRA is a great automation tool for vRA, it wasn’t a seamless integration with Jenkins. The CloudClient had to be installed on the Jenkins slaves and then called as a shell build step.  Functional, but not really ideal.
  2. vRealize Code Stream:  Code Stream has an excellent plugin for Jenkins that allows you to kick off release pipelines which provision vRA blueprints.  This is an excellent option for Code Stream users.

I’ll stress that the Jenkins plugin for vRA is only compatible with vRA 7. The release of vRA 7 brought enhancements to REST API that makes integrating REST calls with vRA 7 simple.   If you are using an older version of vRA (5.x or 6.x) and want Jenkins integration, then you will have to use the CloudClient or Code Stream.

The Jenkins plugin for vRA 7 has been included in the official Jenkins plugin repository and can be installed just like any other Jenkins plugin.  For instructions please visit the plugin’s wiki.  The plugin is open source and the code is available on GitHub.

If you are running vRA 7 and want Jenkins integration, then check out the Jenkins Plugin for vRA 7.

 

Developing a NodeJS app using AppCatalyst

If you own a Mac and are into *nix virtual machines for development, then VMware’s AppCatalyst is a must have because…

AppCatalyst is free!

AppCatalyst is targeting that hip Application/DevOps demographic that loves Macs, Linux, API/Scripting and hates GUIs.  You know the same demographic who also loves free stuff for development!   I resemble that comment…

Who wouldn’t like AppCatalyst?   People with out a Mac, or people running Windows VMs.  For that audience there is still VMware Workstation, Fusion and other virtualization alternatives.

If your still with me, then download the hotness from….

http://getappcatalyst.com/

VM’s Phssssshhhha!  How do I make it useful for development?

I’ll skip the usual unzip instructions as many other blogs have covered the basic install.  The remainder will focus on how to integrate AppCatalyst into your development environment using Vagrant and an IDE, in my case it’s IntelliJ, the result will be a simple NodeJS application.

Vagrants and Containers

I’m talking third platform apps, not your local alley bar.   AppCatalyst is packaged with project Photon, a container run time host.

Download vagrant to your desktop.  https://www.vagrantup.com/

I won’t go through the vagrant install process. It’s easy and well documented on the internet.

Install the AppCatalyst plugin for vagrant.

$ vagrant plugin install vagrant-vmware-appcatalyst

I’m also using project Photon as the container host.  There is a vagrant plugin for photon too!  Install the photon plugin for vagrant.

$  vagrant plugin install vagrant-guests-photon

Now you need a VagrantFile.  No, that’s not someone that has a fetish for vagrants. You know a VagrantFile, like this…


# Set our default provider for this Vagrantfile to 'vmware_appcatalyst'
ENV['VAGRANT_DEFAULT_PROVIDER'] = 'vmware_appcatalyst'

nodes = [
{ hostname: 'nodejs', box: 'vmware/photon' },

]

$ssl_script = <<SCRIPT

echo Setting up SSL...

mkdir -p /tmp/SSLCerts
cd /tmp/SSLCerts
openssl genrsa -aes256 -out ca-key.pem -passout pass:foobar 2048

openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem -subj "/C=US/ST=GA/L=ATL/O=IT/CN=www.inkysea.com" -passin pass:foobar

openssl genrsa -out server-key.pem 2048
HOST=`hostname`
openssl req -subj "/CN=$HOST" -new -key server-key.pem -out server.csr
IP=`ifconfig eth0 | grep "inet\ addr" | cut -d: -f2 | cut -d" " -f1 `

echo "subjectAltName = IP:$IP,IP:127.0.0.1" > extfile.cnf

openssl x509 -req -days 365 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf -passin pass:foobar

openssl genrsa -out key.pem 2048
openssl req -subj '/CN=client' -new -key key.pem -out client.csr
echo extendedKeyUsage = clientAuth > extfile.cnf
openssl x509 -req -days 365 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf -passin pass:foobar

rm -v client.csr server.csr

mkdir -p /vagrant/DockerCerts/

# Purge old certs on client
chmod 755 /vagrant/DockerCerts/*
rm /vagrant/DockerCerts/*

# setup keys for IDE

sudo -u vagrant cp -v {ca,cert,ca-key,key}.pem /vagrant/DockerCerts/
chmod -v 0400 /vagrant/DockerCerts/*key.pem
chmod -v 0444 /vagrant/DockerCerts/ca.pem
chmod -v 0444 /vagrant/DockerCerts/cert.pem

# Setup keys on docker host
chmod -v 0400 ca-key.pem key.pem server-key.pem
chmod -v 0444 ca.pem server-cert.pem cert.pem

cp -v {ca,server-cert,server-key}.pem /etc/ssl/certs/
mkdir -pv /root/.docker
cp -v {ca,cert,key}.pem /root/.docker
mkdir -pv /home/vagrant/.docker
cp -v {ca,cert,key}.pem /home/vagrant/.docker
echo "export DOCKER_HOST=tcp://$IP:2376 DOCKER_TLS_VERIFY=1" >> /etc/profile

# Setup Docker.service and client
SED_ORIG="ExecStart\\=\\/bin\\/docker \\-d \\-s overlay"
SED_NEW="ExecStart\\=\\/bin\\/docker \\-d \\-s overlay \\-\\-tlsverify \\-\\-tlscacert\\=\\/etc\\/ssl\\/certs\\/ca\\.pem \\-\\-tlscert\\=\\/etc\\/ssl\\/certs\\/server\\-cert\\.pem \\-\\-tlskey\\=\\/etc\\/ssl\\/certs\\/server\\-key\\.pem \\--host 0\\.0\\.0\\.0\\:2376"
sed -i "s/${SED_ORIG}/${SED_NEW}/" "/lib/systemd/system/docker.service"

systemctl daemon-reload
systemctl restart docker

SCRIPT

Vagrant.configure('2') do |config|

# Configure our boxes with 1 CPU and 384MB of RAM
config.vm.provider 'vmware_appcatalyst' do |v|
v.vmx['numvcpus'] = '1'
v.vmx['memsize'] = '512'
end

# Go through nodes and configure each of them.j
nodes.each do |node|
config.vm.define node[:hostname] do |node_config|
node_config.vm.box = node[:box]
node_config.vm.hostname = node[:hostname]
node_config.vm.provision "shell", inline: $ssl_script
end
end
end

Dont’ worry about copying and pasting.  I’ve setup a github project for this work.  Feel free to clone the project to your desktop.  The project can be found at https://github.com/inkysea/node-appcatalyst.

The project as three key items for review.

  1. VagrantFile :    This is a configuration script for vagrant.  Vagrant will work with AppCatalyst to magically provision a photon instance, complete with docker daemon and SSL certs so you can  communicate remotely with docker.   Simply type “vagrant up” from the command line and watch the magic!
  2. DockerSettings directory :  Contains a configuration file for docker, container_settings.json.  The configuration file sets values such as listening port, volumes, etc.  The file is used at build time and is useful for times when you don’t use ‘docker run’, like with an IDE.
  3. DockerOut Directory :  Contains DockerFile, .dockerignore and sample nodeJS code.

A. The DockerFile instructs Docker on what to run and install.   The included docker file is installing NPM and some other dependencies for a  nodeJS app.

FROM node:0.10

EXPOSE 8081

# App
ADD ./package.json /tmp/package.json

RUN cd /tmp && \
npm install && \
npm install -g nodemon && \
npm install express

RUN mkdir -p /opt/app && cp -a /tmp/node_modules /opt/app/

ADD . /opt/app

WORKDIR /opt/app

# Execute nodemon on the /app/index.js file. nodemon will poll the file for updates.
CMD ["nodemon", "/app/index.js"]

B. The .dockerignore file is incredibly important if you don’t want docker to fall over after running a couple of containers.  The file works similar to .gitignore but for docker, essentially defining files and directories that should not be placed into the container.  In this example, the node_modules directory is ignored as it can get huge and has no business making it into your container.

.DS_Store

# Node.js
/node_modules

# Vagrant
/.vagrant

/DockerCerts

.git
.gitignore
/.idea
LICENSE
VERSION
README.md
Changelog.md
Makefile
docker-compose.yml

C. index.js is your “hello world” node JS application.

var express = require('express');

// Constants
var DEFAULT_PORT = 8081;
var PORT = process.env.PORT || DEFAULT_PORT;

// App
var app = express();
app.get('/', function (req, res) {
res.send('Hello World!\n');
});

app.listen(PORT)
console.log('Running on http://localhost:' + PORT);

 Run Docker, Run…

Now you are ready to run docker on that fancy photon VM you provisioned earlier with Vagrant and AppCatalyst.     You can run your container using the command line or using an IDE like IntelliJ.

You can setup IntelliJ with the Docker SSL certs that were created by Vagrant earlier.

  • Configure IntelliJ for Docker’s API.  Set the API URL and the Certificates Folder.   The API URL will be the IP of your vagrant VM and the docker API listening on 2376.  The Certificates required for communicating docker are in your projects directory under DockerCerts, they were created by the VagrantFile.

dockerconnection

  • Configure IntelliJ to run docker.  Navigate to “run” -> “edit configurations” and add a “Docker Deployment”.
    • Server:  Set this to the docker provider you configured previously
    • Deployment :  Set this to the DockerFile in the project
    • Container Settings : Set this to your container_settings.json file in the project

dockerrun

  • Deploy your application into a container. 1.  navigating to the “Application Servers” tab on the bottom right of intelliJ.  2. Press the deploy button.

dockerdeploy

  • When docker is done, you will see the following message stating that the container has successfully deployed.

deployedYou can now browse to the IP and Port (http://vagrantIP:8081) of your container to see the hello world message.

browse

Note:   The ability to use code injection for nodeJS with nodemon is very desirable as you can simply update your code and see real time results as it is mapped into the container.  Unfortunately, I haven’t found a way to make this work with the container_settings.json.  In theory you should be able to map a volume in the container settings similar to ‘docker run -v’.    If you want to use code injection then you are stuck using docker run -v at this time.

Selenium on Linux with yum

I’ve setup selenium with Jenkins a few times and I noticed there is no consistent documentation for setting up selenium with PHPUnit.  A search results in several different methods of varying complexity and efficacy.

Instead of going through all that mess just use the EPEL repo…

yum install epel-release

yum install php-phpunit-PHPUnit

yum install php php-xml php-devel php-pdo

yum install php-phpunit-PHPUnit-Selenium

You can probably cat the yum commands together and get the same result.  However, the order above is the way I ran them while stumbling through various documentation.

vRA provisioning with SCCM

Integrating SCCM with vRA to provide a service to build a Windows VM is a very popular request for vRA.  Even if your organization is leveraging clones, you may benefit from integrating SCCM or Linux Kickstart with vRA.   The primary benefit a consistent and visible service to create guest OS templates that can be used for cloning.  This post will cover the integration of an SCCM task sequence that installs Windows 2012 R2 with vRA providing the cloud infrastructure and self service to enable your users to quick produce quality content.

Create a new blueprint that Leverages SCCM

First create a new blueprint. Since we are using SCCM the blueprint could be physical or virtual. For this demonstration we will be using virtual.

Go to the infrastructure tab, blueprints and select Virtual, vSphere to create a new vSphere blueprint that will leverage SCCM.

SCCM_new_blueprint

After you name the blueprint, go to the build information tab to specify the type of VM being created along with compute, memory and storage.

SCCM_build_information

1. We are creating a server blueprint that will create a new VM. Since we are using SCCM we will create a new VM and not be cloning a VM. Finally select the VirtualSCCMProvisioningWorkflow as the workflow to create your VM using SCCM.
2. Specify the desired compute, memory and storage values. Note that minimum storage will be based on the volumes that you add using the “New Volume” button. You must have at least one volume specified as the C: volume. Provide a maximum value for storage if you’d like to allow your users to specify more storage at request time.

Next you’ll define the properties for the VM by navigating to the “Properties” tab.

SCCM_Properties

Build Profiles and Custom Properties

Note that I am leveraging both build profiles and custom properties.

1. A build profile is a group of properties that may be used across blueprints. vRA contains several build profiles out of the box. For example, there is a build profile that provides default properties to be used with SCCM.

2. The custom properties have scope only to the blueprint. I’ve several custom properties set. Some of the properties are required and others are optional based on your needs.

Required properties:
VMware.VirtualCenter.OperatingSystem: Sets VM hardware settings based on the type of OS being used. In this case I am creating a Server 2012 machine and the property is set to windows8Server64Guest

VMware.SCSI.Type: Required only for Server 2012 R2 machines and must be set to lsilogicsas when creating a Server 2012 R2 machine. By default vRA creates a VM with lsilogicparallel. Server 2012 R2 only provides drivers for lsilogicsas.

Optional Properties:
VirtualMachine.Admin.ThinProvision: Set to true to leverage thing provisioning and save on storage. If not specified, the VM is created as thick.

ExternalWFStubs.BuildingMachine: Sets the vRO workflow to be run when building the VM. In this case I am calling a vRO workflow that allocates an IP address from an IPAM system.

ExternalWFStubs.DisposingMachine: Sets the vRO workflow to be run when destroying the VM. In this case I am calling a vRO workflow that gives back the IP address requested from IPAM when building the VM.

To view the properties included with a build profile, select the “Build Profiles” button on the left hand side of the screen. The build profiles screen allows you to view existing build profiles and create new build profiles.

SCCM_build_profiles_1

To create a new build profile, select “New Build Profile”. Provide a name for your build profile. You may either create a build profile on your own or leverage existing build profiles using the “Copy from existing build profile” option. When copying from an existing profile, you notice that vRA includes many useful build profiles right out of the box. vRA does provide a SCCM build profile and we will leverage the out of the box properties.

SCCM_property_set

After selecting the existing SCCM build profile we simply set the values based on our environment. Note that if you want to allow users to alter settings at order time, simply set the property to “prompt user”.

SCCM_build_profile

Modify the SCCM Task Sequence to install the vRA guest agent

Prior to publishing your blueprint for consumption, you must add the vRA guest agent to the SCCM task sequence. The vRA guest agent gets installed by SCCM and then reports back to vRA that the task sequence is complete.

Download the vRA guest agent from the vRA server. The guest agent can be found on your vRA server at the following URL:

https://vra-server:5480/installer/

Unzip the vRA guest agent to a location on the SCCM server. Note the SCCMPackageDefinitionFile.sms file will serve as the definition file when we create the installation package.

SCCM_create_vRA_guest

Create an SCCM package for the vRA guest agent. Ensure that you are creating the package using the “Create Package from Definition” option. Use the browse button to select the SCCMPackageDefinitionFile.sms file.

SCCM_vRA_guest_agent_unzip

Add the vRA guest agent package to the end of the task sequence using “install package”.

SCCM_vRA_task_sequence

We’ve now created the SCCM blueprint and configured the SCCM task sequence to install the vRA guest agent. The blueprint can now be published and consumed by our users.

Managing workload on-premise or on a public cloud? No Sweat!

Recently I was challenged with provisioning an application to both an on-premise cloud and a public cloud. In this example, the on-premise cloud is powered by vSphere and the the public cloud is AWS EC2. I’ll demonstrate how vRealize Automation abstracts both clouds and allows you to easily deploy a simple application (WordPress App) using extensibility with vRealize Orchestrator.

Machine Blueprints

First setup machine blueprints for both your on-premise vSphere workload and your AWS EC2 workload. The blueprints should leverage the same version of OS to make things simple.

Go to the infrastructure tab, navigate to blueprints and select “new blueprint”. You’ll be able to choose from several different clouds and on-premise options. In this example, I’ll leverage the multi-machine blueprints to create an application based on pre-existing single machine blueprints for Linux on vSphere and EC2.

vRA_wordpress_app_1

Creating the multi-machine blueprint for both vSphere and EC2 is pretty much identical.

Ensure that you provide a descriptive name and description.

MM_blueprint_aws_name

Now specify the single machine blueprints to be used in the “Build Information” tab and select “Add Blueprints”.

MM_blueprint_build_info_1

You’ll be provided with a list of single machine blueprints that can be added. Note that I pick the single machine blueprint CentOS Linux 5.6 running on EC2. If I was creating an on-premise blueprint I’d choose the linux blueprint just below.

MM_blueprint_build_info_2

Now that my single machine blueprint has been added, I’ll set the maximum lease for 2 days. Since this is running on EC2 I want to control how long the workload can run to avoid costs.

MM_blueprint_build_info_3

Finally, I’ll add properties that are required to deploy the WordPress application. Note that the properties are identically, regardless of running on vSphere or EC2.

MM_blueprint_properties

Two things to note with the properties…

1. I am leveraging build profiles to contain certain wordpress properties like DB name, password, etc. A build profile essentially allows you to create a group of properties that can be easily reused across blueprints. I’ve named the build profile “WordPress Application” and checked it so that those properties are included in the blueprint.

2. I’m leveraging vRO extensibility to run a custom workflow that will execute on the linux machines and install the word press application. The property “ExternalWFStubs.MachineProvisioned” is used to tell the blueprint to run a vRO workflow once the machines are provisioned in vsphere or EC2. The unique ID of the workflow is 9d200500-6bef-4ab7-96d4-1f8f3b2209f9.

vRO Workflow

How do you guet the unique ID of a vRO workflow? Simply log into vRO, find your workflow and look at the “General” tab. The unique ID of the workflow will be displayed.

vRO_Wordpress_UUID

Since we are deploying to a consistent version of linux, A single workflow can be utilized to deploy wordpress on-premise or on EC2. There is one logic point that should be added to your workflow to decide if the workflow is running on an vSphere or EC2. In the screenshot below, you’ll notice that I highlighted a custom decision point.

vRO_workflow_wordpress

The following code is in the decision point.

IsAWS = vCACVmProperties.get("__amazon.instanceType");

if (!IsAWS || 0 === IsAWS.length){
System.log(“VSphere Instance Type: “);
return false;
}else{
System.log(“AWS Instance Type: “+IsAWS);
return true;
}

If it’s running on EC2 it will direct the workflow down a path that uses the DNSname if it’s running in my on-premise cloud then it will use the IP address.

At this point we have a blueprint and a vRO workflow for deploying the wordpress application. After publishing the blueprints for on-premise and EC2 it’s now available for my users to consume.

vRA_wordpress_app

SCCM Custom Variables in vRealize

vRealize Automation makes it super simple to build a machine with SCCM. If your SCCM task sequence happens to require custom variables, then you can define those variables in vRealize. vRealize will pass those parameters to SCCM.

When using SCCM Custom Variables simply tell vRealize by setting the following property in your blueprint or build profile.

SCCM.RemoveCustomVariablePrefix=true

This property will make use of the “SCCM.CustomVariable.” property feature in vRealize. You’ll now be able to declare all sorts of SCCM properties like “SCCM.CustomVariable.foo” and vRealize will pass the property to SCCM as “foo”!

Check here to read more about SCCM blueprints for vRealize.

Special thanks to Tom Bonanno at DailyHypervisor for working with me on SCCM!

vRealize Automation 6.1 REST API

With vRealize Automation (vCAC) 6.1 you can call REST API’s to request services.
Why is this a big deal?

With a REST API you can easily introduce vRealize Automation into a continuous delivery pipeline with your favorite continuous integration tool, like Jenkins.  I’ll cover how to manage a simple machine lifecycle (provision and destroy) using the REST API.

Choose your REST client

There are several options for REST clients.  REST simply sits over the HTTP protocol. You can even use a command line utility like curl to make REST calls.   To demonstrate vRealize Automation’s REST API I’m using a Firefox plugin called RESTClient.

Papers please!

You must first establish a session with vRealize Automation.  Using the RESTClient you can request a session token using the following steps…

1.  Get ready to POST

Set the method to POST and enter the URL to your vRealize Automation server. You’ll invoke the “tokens” API to get your session.  The URL is below…

https://<vrealize-server>/identity/api/tokens

2.  Set your headers

You must set your HTTP headers, regardless of the REST client.  The steps are slightly different for each client.  For the RESTClient select the “Headers” menu item and then select “Customer Header”.  You’ll enter two headers.

Header 1:   Accept : application/json

Header 2:  Content-Type : application/json

Save each header to your favorites and apply each header.

3.  Set the body

The body is a simple JSON string which includes the user, password and tenant.

{
username:user@inkysea.local,

password:your_password,
tenant:inkysea
}

At this point your RESTClient should look like this…

RESTClient_1

Select send and you will now see a response from the server that includes your token!

RESTClient_2

You’ve got a golden ticket!  Now lets order a VM!

You’ll use the token as an HTTP header for the remainder of your session.

Simply add a new header called “Authorization”.  The value of the header will be

Bearer <Token>

For example:

Bearer MTQxMjA3OTU1ODE5Nzo0MjA0YWU3Y2EwZmVkY2IzYWE2ZDp0ZW5hbnQ
6aW5reXNlYXVzZXJuYW1lOnZjYWNhZG1pbkBpbmt5c2VhLmxvY2FsOjE1NDZ
kZTc3YzVmN2JhYjMwMzBkMmUwNGI5N2MwYjY3NzIxMTdhZjNkOTMyMjJ
mNTA1YmI5MmQ4MDAyYmE0NzdmZTczMjcxMjA2MjQzZTcyYWY3MzU0ZjN
jZWFlOWI4OTg2NDAzYTY2NzhkMWViOGVhMDc3M2Y0NTk3Y2E5NWJm

RESTClient_3


Note that the default session timeout for a token is 24 hours.

If you want to adjust the session timeout you must ssh into the vCAC appliance add the following property

identity.basic.token.lifetime.hours=N

to the /etc/vcac/security.properties file.  Note that N is equal to number of hours.

Wait….I’m entitled to what?

You need a list of services to which you are entitled, like ordering a VM.  Once you get the list you’ll be able to choose the services that you want to order.

Get your entitled items using a GET request…

HTTP Action: GET
URL: https://<vrealize-server>/catalog-service/api/consumer/entitledCatalogItems

The JSON response lists all of the services.  Look at the list and find which service you’d like.  I’m going to order the “CentOS 6.5 x86” service

Sample JSON Response..

{
“@type”: “ConsumerEntitledCatalogItem”,
“catalogItem”: {
“id”: “60c089a1-40b6-4857-813b-7c9faaeb56f2”,
“version”: 3,
“name”: “CentOS 6.5 x86”,
“description”: “Linked Clone”,
“status”: “PUBLISHED”,
“statusName”: “Published”,
“organization”: {
“tenantRef”: “inkysea”,
“tenantLabel”: “inkysea”,
“subtenantRef”: null,
“subtenantLabel”: null
},
“providerBinding”: {
“bindingId”: “86305892-f9d4-448b-a70c-8a588cfe6aca”,
“providerRef”: {
“id”: “e17f0743-20c7-484c-8c16-426e0ee985d6”,
“label”: “iaas-service”
}
},
“forms”: null,
“callbacks”: null,
“isNoteworthy”: false,
“dateCreated”: “2014-09-12T00:33:10.541Z”,
“lastUpdatedDate”: “2014-09-13T02:39:26.717Z”,
“iconId”: “60c089a1-40b6-4857-813b-7c9faaeb56f2”,
“catalogItemTypeRef”: {
“id”: “Infrastructure.Virtual”,
“label”: “Virtual Machine”
},
“serviceRef”: {
“id”: “d922d7c1-ddb7-4fba-a8d9-90bd9688f9f0”,
“label”: “IAAS”
},
“outputResourceTypeRef”: {
“id”: “Infrastructure.Virtual”,
“label”: “Virtual Machine”
}
},

Note that you are interested in the “id” and the “bindingID” that are in bold font.  Save those ID’s for later!  You’ll need the ID to order the service!

I order you to give me a VM!

At this point you are ready to order a VM.  Let’s recap the values we’ll need to place the order over REST.

1.  The ID of the service (id). 60c089a1-40b6-4857-813b-7c9faaeb56f2
2. The name of your tenant (tentatRef). inkysea
3. The internal ID of your tenant (subtenantRef): 5ee95e3f-56a8-4a1b-a14e-62ecea9b84a3″
4.  If you are ordering on behalf of another user (requestedFor): user@inkysea.local

HTTP Action: POST
URL:  https://<vrealize-server>/catalog-service/api/consumer/requests

JSON Body:   Replace the values in bold with values that pertain to your environment.

{

“@type”: “CatalogItemRequest”,
“catalogItemRef”: {
“id”: “60c089a1-40b6-4857-813b-7c9faaeb56f2”
},
“organization”: {
“tenantRef”: “inkysea”,
“subtenantRef”: “5ee95e3f-56a8-4a1b-a14e-62ecea9b84a3”
},
“requestedFor”: “user@inkysea.local”,
“state”: “SUBMITTED”,
“requestNumber”: 0,
“requestData”: {
“entries”: [
{
“key”: “provider-blueprintId”,
“value”: {
“type”: “string”,
“value”: “86305892-f9d4-448b-a70c-8a588cfe6aca”
}
},
{
“key”: “provider-provisioningGroupId”,
“value”: {
“type”: “string”,
“value”: “5ee95e3f-56a8-4a1b-a14e-62ecea9b84a3”
}
},
{
“key”: “requestedFor”,
“value”: {
“type”: “string”,
“value”: “user@inkysea.local”
}
},
{
“key”: “provider-VirtualMachine.CPU.Count”,
“value”: {
“type”: “integer”,
“value”: 1
}
},
{
“key”: “provider-VirtualMachine.Memory.Size”,
“value”: {
“type”: “integer”,
“value”: 1024
}
},
{
“key”: “provider-VirtualMachine.LeaseDays”,
“value”: {
“type”: “integer”,
“value”: 5
}
},
{
“key”: “provider-__Notes”,
“value”: {
“type”: “string”,
“value”: “API request”
}
},
{
“key”: “provider-VirtualMachine.Disk0.Size”,
“value”: {
“type”: “string”,
“value”: “1”
}
},
{
“key”: “provider-VirtualMachine.Disk0.Letter”,
“value”: {
“type”: “string”,
“value”: “C”
}
},
{
“key”: “provider-Cafe.Shim.VirtualMachine.TotalStorageSize”,
“value”: {
“type”: “decimal”,
“value”: 1
}
},
{
“key”: “provider-Cafe.Shim.VirtualMachine.Description”,
“value”: {
“type”: “string”,
“value”: “API request”
}
},
{
“key”: “provider-Cafe.Shim.VirtualMachine.NumberOfInstances”,
“value”: {
“type”: “integer”,
“value”: 1
}
},
{
“key”: “provider-Cafe.Shim.VirtualMachine.Reason”,
“value”: {
“type”: “string”,
“value”: “showcasing API”
}
},
{
“key”: “provider-Cafe.Shim.VirtualMachine.AssignToUser”,
“value”: {
“type”: “string”,
“value”: “user@inkysea.local”
}
},
{
“key”: “provider-Cafe.Shim.VirtualMachine.MinCost”,
“value”: {
“type”: “string”,
“value”: “0”
}
},
{
“key”: “provider-Cafe.Shim.VirtualMachine.MaxCost”,
“value”: {
“type”: “string”,
“value”: “0”
}
},
{
“key”: “description”,
“value”: {
“type”: “string”,
“value”: “API request”
}
},
{
“key”: “reasons”,
“value”: {
“type”: “string”,
“value”: “showcasing API”
}
}
]
}
}

Inside the vRealize Automation portal you now see your VM request!

vRealize_1

Look at the request!

Looking at the request is optional.  The REST call to provision the VM will return a URL to the request in it’s response header.  The URL for request will look similar to https://<vrealize-server>/catalog-service/api/consumer/requests/

For example:

https://<vrealize-server>/catalog-service/api/consumer/requests/32ebbfb6-302e-4f28-a4c8-a8fb64780cb5

You can also ask vRealize for a list of all your requests.  Just remove the request ID from the URL

https://<vrealize-server>/catalog-service/api/consumer/requests/

List My VMs

At this point we’ve ordered a VM and we have the request ID.  You can now search for the ID of the VM that you provisioned by using the request ID.

HTTP Action:  GET
URL:  https://<vrealize-server>/catalog-service/api/consumer/resources/types/Infrastructure.Machine

JSON RESPONSE:

{
“@type”: “CatalogResource”,
“id”: “92c91b2e-cce0-458d-94af-22efea192669”,
“iconId”: “60c089a1-40b6-4857-813b-7c9faaeb56f2”,
“resourceTypeRef”: {
“id”: “Infrastructure.Virtual”,
“label”: “Virtual Machine”
},
“name”: “dev-119”,
“description”: “API request”,
“status”: “ACTIVE”,
“catalogItem”: {
“id”: “60c089a1-40b6-4857-813b-7c9faaeb56f2”,
“label”: “CentOS 6.5 x86”
},
“requestId”: “32ebbfb6-302e-4f28-a4c8-a8fb64780cb5”,
“providerBinding”: {
“bindingId”: “4e8838d8-f676-480b-bb02-026f8b837cd7”,
“providerRef”: {
“id”: “e17f0743-20c7-484c-8c16-426e0ee985d6”,
“label”: “iaas-service”
}
},
“owners”: [
{
“tenantName”: “inkysea”,
“ref”: “user@inkysea.local”,
“type”: “USER”,
“value”: “user@inkysea.local”
}
],
“organization”: {
“tenantRef”: “inkysea”,
“tenantLabel”: “inkysea”,
“subtenantRef”: “5ee95e3f-56a8-4a1b-a14e-62ecea9b84a3”,
“subtenantLabel”: “inkysea_developers”
},
“dateCreated”: “2014-09-30T13:24:13.522Z”,
“lastUpdated”: “2014-09-30T13:24:17.651Z”,
“hasLease”: true,
“lease”: {
“start”: “2014-09-30T13:21:23.000Z”
},
“leaseForDisplay”: null,
“hasCosts”: true,
“costs”: {
“leaseRate”: {
“type”: “moneyTimeRate”,
“cost”: {
“type”: “money”,
“currencyCode”: “USD”,
“amount”: 0.58
},
“basis”: {
“type”: “timeSpan”,
“unit”: “DAYS”,
“amount”: 1
}
}
},
“costToDate”: {
“type”: “money”,
“currencyCode”: “USD”,
“amount”: 0.58
},
“totalCost”: null,
“childResources”: [],
“operations”: [
{
“name”: “Change Lease”,
“description”: “Change the lease for a machine.”,
“iconId”: “machineChangeLease.png”,
“type”: “ACTION”,
“id”: “9c41cebc-e250-44ff-91a1-d24e02cd82cc”,
“extensionId”: null,
“providerTypeId”: “com.vmware.csp.iaas.blueprint.service”,
“bindingId”: “Infrastructure.Machine.Action.ChangeLease”,
“hasForm”: true,
“formScale”: “SMALL”
},
{
“name”: “Connect by Using VMRC”,
“description”: “Infrastructure connect using VMRC”,
“iconId”: “cafe_default_icon_genericResourceOperation”,
“type”: “EXTENSION”,
“id”: “85308de5-bfd7-4dfb-98d8-619547578fd7”,
“extensionId”: “csp.places.iaas.item.window.ConnectViaVmrc”,
“providerTypeId”: null,
“bindingId”: null,
“hasForm”: false,
“formScale”: null
},
{
“name”: “Destroy”,
“description”: “Destroy a virtual machine.”,
“iconId”: “virtualDestroy.png”,
“type”: “ACTION”,
“id”: “e0f1d583-00bd-4975-aad8-dff27cb9b76f”,
“extensionId”: null,
“providerTypeId”: “com.vmware.csp.iaas.blueprint.service”,
“bindingId”: “Infrastructure.Virtual.Action.Destroy”,
“hasForm”: false,
“formScale”: null
},

There are two items you’ll need from the JSON response.  I’ve highlighted them both in bold black text in the JSON response above.

The two values are…

The VM ID (id): 92c91b2e-cce0-458d-94af-22efea192669
The Destroy action ID (id): e0f1d583-00bd-4975-aad8-dff27cb9b76f

Note: It is possible to filter the results based on ID.  Filtering will limit the content returned in the JSON response.

Note:  You can also get the list of actions allowed by querying /consumer/resources/<VM_ID>/action

HTTP Action:  GET
URL:  https://<vrealize-server>/catalog-service/api/consumer/resources/92c91b2e-cce0-458d-94af-22efea192669/action

Crush, Kill, Destroy

Now we are ready to destroy the machine and complete the lifecycle. Use the JSON body below to destroy your machine

1. The ID of your VM(resourceRef): 92c91b2e-cce0-458d-94af-22efea192669
2. The Destroy action ID (resourceActionRef): e0f1d583-00bd-4975-aad8-dff27cb9b76f
3. The tenant name in vCAC (tenantRef and tenantLabel) : inkysea
4. The name of your vCAC business group (subtenantLabel) :  inkysea_developers
5. The internal ID of the vCAC business group (subtenantRef):5ee95e3f-56a8-4a1b-a14e-62ecea9b84a3

HTTP Action: POST
URL: https://<vrealize-server>/catalog-service/api/consumer/requests

JSON Body:   Replace bolded text with values for your environment

{
“@type”: “ResourceActionRequest”,
“resourceRef”: {
 “id”: “92c91b2e-cce0-458d-94af-22efea192669”
},

“resourceActionRef”: {
“id”:”e0f1d583-00bd-4975-aad8-dff27cb9b76f”
},

“organization”: {
“tenantRef”: “inkysea”,
“tenantLabel”: “inkysea”,
“subtenantRef”: “5ee95e3f-56a8-4a1b-a14e-62ecea9b84a3”,
“subtenantLabel”: “inkysea_developers”
},

“state”: “SUBMITTED”,
“requestNumber”: 0,
“requestData”: {
“entries”: []
}
}

Additional references
You can find more information about the REST API in the Programing Guide and REST API Documentation included with the vRealize Automation Documentation