Monthly Archives: December 2014

vRA provisioning with SCCM

Posted on December 30, 2014 | 12 comments

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.

12 Comments

Posted in Uncategorized

Tagged ,

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

Posted on December 28, 2014 | 2 comments

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

2 Comments

Posted in Uncategorized

Tagged , ,