In vRealize Automation you have two methods for requesting virtual machines in the self-service portal:
- Publish the blueprint that you’ve created in the converged blueprint designer to the vRA catalog. With this method the blueprint is directly published in the portal.
- Create a Advanced Service Designer (ASD) XaaS blueprint that is published in the self-service portal. The XaaS blueprint is used to do the request of the actual blueprint as discussed in option 1.
Both options have their pros and cons. Option 1 is the default method that most people will use; it’s quick and works straight forward. You can customize the request form to some extent and at custom properties. You can also add form interaction if required using vRO actions. Although the customization options for this kind of forms improved with the release vRA 7.x, you will still face limitations if you have specific customization requirements. For example: some organizations want to have one request form that is linked to different blueprints, or you want to customize the appearance of form you will face unsolvable challenges. In this case option 2 comes into the picture.
With options 2, using the ASD and XaaS blueprints, you can create the request exactly the way you want it. On top of this, it is possible to bundle different blueprints in one request. This is a two-step-process: You prepare the blueprint request using the ASD, and when it’s finished you do the actual request of the blueprint. An additional great benefit of this method is that a check is performed concerning the required resources for the requested virtual machine, before the actual request is submitted. Some vRA implementations that use option 1 add extra resources in the BuildingMachine phase (for example because of some t-shirt sizing functionality). Although this works fine, the check for required resources is performed before the BuildingMachine phase. This means you don’t have any guarantees the required extra resources that are allocated in the vRO workflow are actually available. Again, with option 2 (ASD/XaaS) you first prepare the request and then submit the request, this guarantees required resources are available and allocated. If resources are not available the request will fail.
In vRealize Orchestrator (vRO) you can find the workflow “Request a catalog item with provisioning request” template, that can be used to build a XaaS blueprint/ASD request. Although I will not go into detail how to build such a request, we will have a look at the JavaScript code that works behind the scenes, I’ve added some comments to explain how this example works.
The following code is from the Request a catalog item with provisioning request workflow in vRO:
//Create a provisioning request for a catalogItem (blueprint) in the portal
var provisioningRequest = vCACCAFERequestsHelper.getProvisioningRequestForCatalogItem(catalogItem);
//Set some parameters
provisioningRequest.setDescription(description);
provisioningRequest.setReasons(reasons);
if(requestedFor){
//Set a different user if this request is for somebody else
provisioningRequest.setRequestedFor(requestedFor);
}
provisioningRequest.setBusinessGroupId(catalogItem.getOrganization().getSubtenantRef());
//Change some data in the JSON request, in this example increase the number of CPUs to 2.
var jsonData = vCACCAFERequestsHelper.getProvisioningRequestData(provisioningRequest);
var json = JSON.parse(jsonData);
//Change cpu example
json.ComponentName.data.cpu = 2;
vCACCAFERequestsHelper.setProvisioningRequestData(provisioningRequest, JSON.stringify(json));
//Do the actual request
request = System.getModule("com.vmware.library.vcaccafe.request").requestCatalogItemWithProvisioningRequest(catalogItem, provisioningRequest);
This example is included on most blogs; it discusses how you can change the number of CPUs or the amount of memory. In the rest of this article I will have a closer look at how to change the disk configuration: to be more specific, how to add an extra disk to the request.
The part where the JSON string is manipulated is the most interesting in the provided example: all parameters that are included in the request are available as a JSON string. The JSON string is converted to a JavaScript object with JSON.parse(jsonData). Then one of the properties is changed (in this example, json.ComponentName.data.cpu=2), in next step the json JavaScript object is converted back to a JSON string (JSON.stringify) and linked to the request.
Note that ComponentName in this example is the name of virtual machine in the blueprint. Since vRA 7.x you have the universal blueprint construct, which is a framework around the components that are included in the blueprint. If a blueprint contains one virtual machine, you have the blueprint construct and a virtual machine that is part of this construct. If we look at the JSON this means you have to point to a virtual machine, for this you have to use the ComponentName property. So let’s say the VM in blueprint is name Linux, you will get:
json.Linux.data.cpu = 2;
If you’re using dots in the VM name (for example centOS-7.0) there’s another syntax you have to use:
json["centOS-7.0"].data.cpu = 2;
I’ve included the structure of the JSON in the next picture. Use a JSON reader for this, I’m using VisualJSON for this:
As you can see, json[“centOS-7.0”].data.cpu = 1 and json[“centOS-7.0”].data.memory = 2048.
When it comes to disks you see an array is used to build the disk configuration. Let’s zoom into this:
In this example you see one disk (available in position 0), with 16 GB of capacity:
json["centOS-7.0"].data.disks[0].data.capacity=16
Adding an extra disk to the request can be achieved by adding an extra cell to the array. Let’s take a look at the following javascript code that will accomplish this:
disk = new Properties(); //create disk properties object
diskdata = new Properties(); //create disk data object
//Set the properties at the data level
diskdata.capacity = "35";
diskdata.custom_properties = null;
diskdata.initial_location = "";
diskdata.is_clone = false;
diskdata.label = "Hard disk 2";
diskdata.userCreated = true;
diskdata.volumeId = 1;
//Set the properties on the disk object.
disk.classId = "Infrastructure.Compute.Machine.MachineDisk";
disk.componentId = null;
disk.componentTypeId = "com.vmware.csp.iaas.blueprint.service";
disk.typeFilter = null;
//Add diskdata properties object to the disk object
disk.put ("data",diskdata);
//Now push the new cell to the disks array in the JSON object
json["centOS-7.0"].data.disks.push (disk);
As you can see the second disk is now part of the JSON object:
The actual request will show the second disk in the vRA GUI interface:
To make the request work it’s important that the configuration of the blueprint allows increasing the disk size:
That’s it, I hope this was useful.
8 Comments
Dan Cohen
Awesome post, very helpful
btw, how can you change the existing disk properties(disk id 0)?
Dan Cohen
Oh, disregard my last comment.
I missed that part
Stacey
Hello…..Thanks, I think this is just what we need but being absolutely new to vRA, can you please point me on raeding material to learn how to :
In vRealize Orchestrator (vRO) you can find the workflow “Request a catalog item with provisioning request” template, that can be used to build a XaaS blueprint/ASD request. Although I will not go into detail how to build such a request, we will have a look at the JavaScript code that works behind the scenes, I’ve added some comments to explain how this example works.
The exact problem is that the user will specify a size for the database, and then the flow will have to do some calculations to determine the disk size based on that. Your post explains how to add the disk into the json object, but my quesitons are 1) how to get that databasize size from the blueprint pulled in and 2) how to actually hook up that workflow to the XaaS blueprint.
viktorious
If you ask the user for the database size, you can just do you calculations and add the output to the json[“centOS-7.0”].data.disks[0].data.capacity=XX value I guess?
Jason
Anybody have any ideas how to update the target datacenter when updating the JSON values for XaaS provisioning of machine blueprints? I see lots of guides on modifying CPU, Memory, Disk. What about setting the target datacenter or reservation policy? I’ve tried update the “datacenter_location” property on the individual machine components from null to siteA but it does not seem to set the datacenter site.
viktorious
Hi, I haven’t dealt with this issue personally but I see there’s a custom property called “__reservationPolicyID”. Maybe this property is the one you need? Make also sure that the template you want to use is available in the other reservation you’re deploying to. The requester has to have access to this reservation as well.
Jacob
I have used this method to create additional drives during provisioning so the customer can add custom drives but the issue we are running into is that it’s adding the additional drives to a vmdk file in a separate folder. Ultimately this hasn’t affected anything as yet but we are running into issues expanding the disk drives after being built. Has anyone seen this issue?
Vaibhav Srivastava
Hi, I am trying to the same thing for AWS EC2 blueprint but when I am trying to add ebs volume in the same way as u described above it shows the error as Cannot call method “push” of null .
I am trying to to follow the above steps as you mentioned for creating json same as below;-
{
“key”: “ebs_storage_volumes”,
“value”: {
“type”: “multiple”,
“elementTypeId”: “COMPLEX”,
“items”: [
{
“type”: “complex”,
“componentTypeId”: “com.vmware.csp.iaas.blueprint.service”,
“componentId”: null,
“classId”: “Infrastructure.Compute.Amazon.EBSVolume”,
“typeFilter”: null,
“values”: {
“entries”: [
{
“key”: “owner”,
“value”: {
“type”: “string”,
“value”: “”
}
},
{
“key”: “size”,
“value”: {
“type”: “integer”,
“value”: 1
}
},
{
“key”: “volumeId”,
“value”: {
“type”: “string”,
“value”: “”
}
},
{
“key”: “name”,
“value”: {
“type”: “string”,
“value”: “one”
}
},
{
“key”: “description”,
“value”: {
“type”: “string”,
“value”: “”
}
},
{
“key”: “location”,
“value”: {
“type”: “string”,
“value”: “”
}
},
{
“key”: “id”,
“value”: {
“type”: “integer”,
“value”: 0
}
},
{
“key”: “toBeAttached”,
“value”: {
“type”: “boolean”,
“value”: true
}
},
{
“key”: “toBeDeleted”,
“value”: {
“type”: “boolean”,
“value”: false
}
},
{
“key”: “device”,
“value”: {
“type”: “string”,
“value”: “xvdb”
}
},
{
“key”: “userCreated”,
“value”: {
“type”: “boolean”,
“value”: true
}
}
]
}
},
{
“type”: “complex”,
“componentTypeId”: “com.vmware.csp.iaas.blueprint.service”,
“componentId”: null,
“classId”: “Infrastructure.Compute.Amazon.EBSVolume”,
“typeFilter”: null,
“values”: {
“entries”: [
{
“key”: “owner”,
“value”: {
“type”: “string”,
“value”: “”
}
},
{
“key”: “size”,
“value”: {
“type”: “integer”,
“value”: 2
}
},
{
“key”: “volumeId”,
“value”: {
“type”: “string”,
“value”: “”
}
},
{
“key”: “name”,
“value”: {
“type”: “string”,
“value”: “two”
}
},
{
“key”: “description”,
“value”: {
“type”: “string”,
“value”: “descroitpion”
}
},
{
“key”: “location”,
“value”: {
“type”: “string”,
“value”: “”
}
},
{
“key”: “id”,
“value”: {
“type”: “integer”,
“value”: 1
}
},
{
“key”: “toBeAttached”,
“value”: {
“type”: “boolean”,
“value”: true
}
},
{
“key”: “toBeDeleted”,
“value”: {
“type”: “boolean”,
“value”: false
}
},
{
“key”: “device”,
“value”: {
“type”: “string”,
“value”: “xvdc”
}
},
{
“key”: “userCreated”,
“value”: {
“type”: “boolean”,
“value”: true
}
}