Category Archives: Uncategorized

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