Import a Package from a Folder in vRO 7.0.1

vRO 7.0.1 in Design mode contains a new toolbar button in Packages; Import package from folder:

ImportFromFolder01

Previously it was possible to export a vRO package to either a zip file or directly to a folder, but only import back from a zip file.

For example, take the following package com.jm.test, which contains 3 workflows and 1 action:
ImportFromFolder02ImportFromFolder03ImportFromFolder04

Exported to a folder test, we get the following:

ImportFromFolder05 ImportFromFolder06 ImportFromFolder07

 

Now in a clean vRO server, I currently do not have those workflows:

ImportFromFolder07b

If I select the Import Package from folder button, I can browse to the folder contained the previously exported to a folder package:

ImportFromFolder08

Then the process to import the package is the same as in the previous vRO versions when importing from a zip file:

ImportFromFolder09

ImportFromFolder10

and now I can use the workflows and action

ImportFromFolder11

ImportFromFolder12

 

Not only is this very handy, it is potentially significant, because it may make it slightly easier to integrate vRO workflow development with source control systems.

vRO requestCatalogItem from vRA Action – Available Properties

The vRO Action requestCatalogItem in the com.vmware.library.vcaccafe.request folder can be used to programmatically request an item from a vRA Catalog.

RequestCatalogItem01

One of the inputs is a properties object which permits you to dynamically make changes to settings configured within the Catalog Item you are deploying from. So say for instance the Catalog Item maps to a Blueprint configured with 1 vCPU, you could change this at request time to be 2 vCPU – which for instance might lead you to needing to maintain fewer Catalog Items.

It’s possible that it exists already, but I haven’t been able to find where the entire list of available properties that you can use are documented. Many of those starting VirtualMachine. or VMware. can be found in the vRA Custom Properties guide, so I’m not going to list them all here. However, not every available property in those ranges actually appear to be in that guide.

So I have decided to maintain a list here garnered from various sources, including a few common ones from the Custom Properties guide. If you know of any others not in the Custom Properties guide, then please leave a comment and I’ll add them:
provider-blueprintId: vRA Blueprint
provider-ProvisioningGroupId: Business Group

provider-VirtualMachine.CPU.Count:
provider-VirtualMachine.Memory.Size:
provider-VirtualMachine.NetworkX.NetworkProfileName: Network profile for NIC 0
provider-VirtualMachine.NetworkX.Name: Network Name (portgroup) for NIC 0

provider-VirtualMachine.DiskX.IsClone:
provider-VirtualMachine.DiskX.Size:

provider-VirtualMachine.DiskX.StorageReservationPolicy: vRA Storage Reservation Policy
provider-VirtualMachine.DiskX.StoragePolicy.FriendlyName: vCenter Storage Policy
provider-VirtualMachine.DiskX.StoragePolicy.vCenterStoragePolicy: vCenter Storage Policy

provider-VirtualMachine.LeaseDays

provider-VMware.VirtualCenter.Folder: Virtual Center folder
provider-Cafe.Shim.VirtualMachine.TotalStorageSize:
provider-Cafe.Shim.VirtualMachine.Description: Description
provider-Cafe.Shim.VirtualMachine.AssignToUser: vRA Machine owner
provider-Cafe.Shim.VirtualMachine.NumberofInstances: Number of VMs to deploy
provider-CustomPrefix
provider-__reservationPolicyID: vRA Reservation Policy

 

Create a vRA Tenant and set Directory and Administrator Configuration with PowervRA

One of the reasons behind creating PowervRA was as a consultant I often have the need to quickly spin up vRA Tenants and / or components within those Tenants to facilitate development or testing work of other things I am automating. PowervRA contains three functions, which when joined together would make a basic vRA Tenant available for use: New-vRATenant, New-vRATenantDirectory and Add-vRAPrincipalToTenantRole.

The following code example demonstrates how to use these in conjunction with each other to make a vRA Tenant (make sure to first of all have generated an API token with Connect-vRAServer with an account that has permission to create a vRA Tenant):

Note that since New-vRATenantDirectory has a lot of parameters, I have taken advantage of the ability to instead provide the necessary JSON text directly to it.

The result is a fresh vRA Tenant with a Directory configured and admin accounts assigned to both the Tenant Admins and Infrastructure Admins roles:

CreateTenantPowervRA02

 

CreateTenantPowervRA01

Find the vRO Workflow ID for an Advanced Service Blueprint with PowervRA

A colleague asked me the other day about how it might be possible to find out which vRO workflow was mapped to an Advanced Service Blueprint (or XaaS Blueprint) in vRA. If you look in the vRA GUI after a Service Blueprint has been created you can’t see which vRO workflow is mapped.

During the creation of the Service Blueprint there is a Workflow tab to select the vRO Workflow:

ServiceBlueprintPowervRA01

 

However, once it has been created, there is no longer a Workflow tab, so you can’t see which vRO workflow is used:
ServiceBlueprintPowervRA02

By using PowervRA though we find this information. The object returned by Get-vRAServiceBlueprint contains a WorkflowId property:

ServiceBlueprintPowervRA03

We can now take that WorkflowId and find the corresponding workflow in vRO. Unless you have memorised all of the workflow IDs then you can issue a REST request to vRO to find out more. The following example uses PowerShell to query the vRO REST API for the WorkflowID above (note that we have to deal with self-signed certificates):

If we look at the data stored in the Workflows variable, we can see the name of the workflow in vRO (OK in this example it’s the same name as the Service Blueprint, but it might well not be in another example):

ServiceBlueprintPowervRA04

Also, if you look at $Workflows.relations.link you will see the first result shows the path in vRO to track down the workflow:ServiceBlueprintPowervRA05

i.e., it can be found in the top-level folder named Test:

 

ServiceBlueprintPowervRA06

Automate vRealize Automation with PowerShell: Introducing PowervRA

While putting together the PowerCLI book 2nd Edition we initially included in the proposed Table of Contents a chapter on vRealize Automation. However, it was fairly apparent that at that time (early 2015) there wasn’t a lot which could be done to fill out the chapter with good content. Firstly, most of the relevant content would be included in the vRO chapter, i.e. use vRA to call a vRO workflow to run PowerShell scripts. Secondly, automating elements within vRA 6.x could be done in part via the REST API, but a) there was a roughly 50 / 50 split between what was in the REST API vs Windows IaaS and b) I didn’t really have the time to make both a PowerShell toolkit for vRA and write a book about PowerCLI.

So we shelved that chapter and I put the thought to the back of my mind that I would revisit the idea when vRA 7 came out and the likelihood of greater coverage in the vRA REST API. At the start  of 2016 this topic came up in a conversation with Xtravirt colleague Craig Gumbley who it turned out had the same idea for making a PowerShell vRA toolkit. So we decided to combine our efforts to produce a PowerShell toolkit for vRA for both our own use as consultants and also to share with the community; consequently the project PowervRA was born.

Initial Release

For the initial release we have 60 functions available covering a sizeable chunk of the vRA 7 REST API. Compatibility is currently as follows:

vRA: version 7.0 – some of the functions may work with version 6.2.x, but we haven’t tested them (yet). Also, they have not been tested with 7.0.1.

PowerShell: version 4 is required.  We haven’t tested yet with version 5, although we wouldn’t expect significant issues.

You can get it from Github  or the PowerShell Gallery

We have provided an install script on Github if you are using PowerShell v4. If you have v5 you can get it from the PowerShell Gallery with:

Getting Started

Get yourself a copy of the module via one of the above methods or simply downloading the zip, unblocking the file and unzipping,  then copying it to somewhere in your $env:PSModulePath.

PowervRA01

PowervRA02

Import the module first:

You can observe the functions contained in the module with the following command:

Before running any of the functions to do anything within vRA, you will first of all need to make a connection to the vRA appliance. If you are using self signed certificates, ensure that you use the IgnoreCertRequirements parameter. :

You’ll receive a response, which most importantly contains an authentication token. This response is stored automatically in a Global variable: $vRAConnection. Values in this variable will be reused when using functions in the module, which basically means you don’t need to get a new authentication token each time, nor have to specify it with a function – it’s done for you.

Each of the functions has help built-in, alternatively you can visit this site http://powervra.readthedocs.org

Example Use Case: Create a vRA Tenant

Having made a connection to the appliance, it’s now time to start using some of the functions. To create a Tenant in vRA we need to have made a connection to vRA with an account that has permissions to do so in the default tenant (typically [email protected]) and then it is as simple as the following:

PowervRA03

PowervRA04

If you look through the rest of the functions, you may notice that a lot of them contain a JSON parameter. So if you know the JSON required for the REST API request or are working with a system that produces it as an output, you can do something like the following:

The Future

VMware may put out something official at some point (I have no inside info on that, it could be weeks, months, years away or not even planned right now). Until that happens Craig and I have various things planned including greater coverage of the API, dealing with any feedback from this release and looking at automating some of our own testing so that we can more easily figure out which vRA versions are supported.

In the meantime, fill your boots and if you want to help us, feel free to get involved via the Develop branch on GitHub.

 

Troubleshooting the vSphere Initial Setup vRO Workflow in vRA 7

Part of the wizard to setup vRA 7 includes a step towards the end to create a vRO workflow that will create initial content within a vRA Tenant. To run the workflow, login to the default vRA tenant as the configurationadmin account created as part of the initial setup:

InitialConfig01

There are various inputs required depending on such things as if you wish to use the default Tenant or create an additional one:

InitialConfig02

What to do though if the workflow fails for some reason? Particularly if you are using the vRO server which is included as part of the vRA appliance, where do you go to look at what went wrong?

You can firstly look at the request in vRA:

InitialConfig03

 

InitialConfig04

If you are using the built-in vRO rather than an external one, you may not know the details to get into it. To access the vRO server that ships as part of the vRA appliance, point your vRO client at the vRA appliance and note a couple of things:

  • The Host name requires port 443 specified
  • The default User name is [email protected]

InitialConfig05

Note: If you don’t have the version 7 client installed, you can run it from the vRA appliance webpage https://vraappliance.fqdn:

InitialConfig06

Once in the vRO client, navigate to Library / vRealize Automation / InitContent / vSphere Initial Setup and you can examine further what went wrong:

InitialConfig07

 

vRA “Internal error: Error allocating network on machine. Attempted to divide by zero”

vRA 6.2.2: while attempting to deploy a VM from blueprint we received the following error:

Internal error: Error allocating network on machine. Attempted to divide by zero

Pretty helpful error message as usual for this version of the product 😉

The Network Profile and Path appeared to be set correctly when requesting the VM. We eventually tracked it down to the Network Profile IP Range having run out of unallocated IPs. The solution of course is to free up some IPs. Head to the Network Profile, IP Ranges to  check out which ones might be suitable to free up:

NetworkProfile01

Once you have removed a VM the IP will go into the Destroyed state for a while (I believe it is 30 mins, couldn’t find a document to confirm)

NetworkProfile02

To speed things up you can hit the Reclaim button:

NetworkProfile03

and the IP should got to the Unallocated state:

NetworkProfile04

Fire up the provision VM task again and things should be better now.

Create Blueprints in vRA 7 via REST and via vRO

A significant pain point on a recent project of mine was automating the creation of blueprints in vRA 6.2 with vRO. There was very little information around on how this could be achieved and even with the method that we eventually came up with still required some manual effort and was not always the most reliable.

Enter vRA 7 and some hope that things may have gotten better.

First of all I looked through the vRA 7 Programming Guide and found some examples on exporting content from vRA 7. I’d heard in some of the conversations around the release of version 7 that blueprints would be able to be manipulated in YAML files, so the first thing to do was to create a blueprint through the new Design interface and then get it exported out into a YAML file.

Create a Blueprint through the Design Interface

Here’s my Centos-Small blueprint created through the Blueprint Designer. A simple vCenter template clone connected to a single network and basic resource values (make sure to publish the blueprint):

CreateBlueprint02

Get an Authentication Token for vRA REST Queries

Using the Postman REST client, I first of all need to get an authentication token. I have previously detailed how to do this from vRO, however from Postman I need to set the following:

URL: https://vraapliance.fqdn/identity/api/tokens

Type: POST

Headers: Accept: application/json and Content-Type: application/json

Body:


{
"username":"[email protected]",
"password":"[email protected]",
"tenant":"Tenant01"
}

CreateBlueprint03

 

CreateBlueprint04

Sending that request should give me a response with a token to use which is valid for up to 8 hours; it will look something like this:


{
"expires": "2016-01-19T18:37:42.000Z",
"id": "MTQ1MzE5OTg2MjYzMTo3MThjNGFiNDVmMjE4MjZiMzgxNjp0ZW5hbnQ6VGVuYW50MDF1c2VybmFtZTp0ZW5hbnRhZG1pbjAxQHZyYWRlbW8ubG9jYWxleHBpcmF0aW9uOjE0NTMyMjg2NjIwMDA6ZmJmZjU2ZmNjOTFkMDE3ODhkNjJmMzM3ZGMwMzM3NjRhMjQxNjJlMjhjMGU3YjU0YzNlZjUwYTlkYWFjNDAxYTBkODVlYzVkYWQ1YzY4ZDc0MTQ3NjBlM2Q3MDk1OGU5OTg1NjNiMTI4OWQwMGMzMzExMDAxNmEyOGY0M2MxYTk=",
"tenant": "Tenant01"
}

 

CreateBlueprint05

Get a List of Blueprints

Now we can use that token to get a list of available blueprints that token has permission to view:

URL: https://vraapliance.fqdn/content-management-service/api/contents

Type: GET

Headers: Accept: application/json and Authorization: Bearer MTQ1MzE5OTg2MjYzMTo3MThjNGFiNDVmMjE4MjZiMzgxNjp0ZW5hbnQ6VGVuYW50MDF1c2VybmFtZTp0ZW5hbnRhZG1pbjAxQHZyYWRlbW8ubG9jYWxleHBpcmF0aW9uOjE0NTMyMjg2NjIwMDA6ZmJmZjU2ZmNjOTFkMDE3ODhkNjJmMzM3ZGMwMzM3NjRhMjQxNjJlMjhjMGU3YjU0YzNlZjUwYTlkYWFjNDAxYTBkODVlYzVkYWQ1YzY4ZDc0MTQ3NjBlM2Q3MDk1OGU5OTg1NjNiMTI4OWQwMGMzMzExMDAxNmEyOGY0M2MxYTk=

CreateBlueprint06

 

This will give us a JSON response, including some details of our Centos-Small Blueprint:


{
"links": [],
"content": [
{
"@type": "Content",
"id": "78f27bc8-dd51-4c10-97cf-fb5770f0836b",
"contentId": "cfa3b28a-6a59-4a85-8355-ff70c6fd3332",
"name": "IaaS VC VirtualMachine",
"description": null,
"contentTypeId": "xaas-resource-mapping",
"mimeType": null,
"tenantId": "_internal",
"subtenantId": null,
"dependencies": [],
"createdDate": "2016-01-05T11:05:21.673Z",
"lastUpdated": "2016-01-05T11:05:21.673Z",
"version": 0
},
{
"@type": "Content",
"id": "3ac8d4ed-1bc0-45d7-a54a-edb44a2fdeae",
"contentId": "9fd01109-c9ab-4ce7-9b9d-4d1c06bccdb9",
"name": "IaaS vCD VM",
"description": null,
"contentTypeId": "xaas-resource-mapping",
"mimeType": null,
"tenantId": "_internal",
"subtenantId": null,
"dependencies": [],
"createdDate": "2016-01-05T11:05:21.868Z",
"lastUpdated": "2016-01-05T11:05:21.868Z",
"version": 0
},
{
"@type": "Content",
"id": "2359c8c9-1ec1-4162-a9e0-aa2c5121815d",
"contentId": "CentosSmall-12345",
"name": "Centos - Small",
"description": "Centos - Small",
"contentTypeId": "composite-blueprint",
"mimeType": null,
"tenantId": "Tenant01",
"subtenantId": null,
"dependencies": [],
"createdDate": "2016-01-19T10:56:14.398Z",
"lastUpdated": "2016-01-19T10:56:14.398Z",
"version": 0
}
],
"metadata": {
"size": 20,
"totalElements": 3,
"totalPages": 1,
"number": 1,
"offset": 0
}
}

Create a Content Package Containing our Blueprint

Now we need to create a Content Package containing our Blueprint, so that it can be exported. We will only add a single item, but multiple items can be added to the Package. The id of the Blueprint retrieved above needs to be used in the JSON body as ‘contents’ .

URL: https://vraapliance.fqdn/content-management-service/api/packages

Type: POST

Headers: Accept: application/json, Content-Type: application/json and Authorization: Bearer MTQ1MzE5OTg2MjYzMTo3MThjNGFiNDVmMjE4MjZiMzgxNjp0ZW5hbnQ6VGVuYW50MDF1c2VybmFtZTp0ZW5hbnRhZG1pbjAxQHZyYWRlbW8ubG9jYWxleHBpcmF0aW9uOjE0NTMyMjg2NjIwMDA6ZmJmZjU2ZmNjOTFkMDE3ODhkNjJmMzM3ZGMwMzM3NjRhMjQxNjJlMjhjMGU3YjU0YzNlZjUwYTlkYWFjNDAxYTBkODVlYzVkYWQ1YzY4ZDc0MTQ3NjBlM2Q3MDk1OGU5OTg1NjNiMTI4OWQwMGMzMzExMDAxNmEyOGY0M2MxYTk=

Body:


{
"name":"Test package",
"description":"Test package for export",
"contents":[ "2359c8c9-1ec1-4162-a9e0-aa2c5121815d" ]
}

CreateBlueprint07

 

CreateBlueprint08

All being well, we should receive a 201 Created response:

CreateBlueprint09

 

Listing Existing Content Packages

We can see what Content Packages are available with:

URL: https://vraapliance.fqdn/content-management-service/api/packages

Type: GET

Headers: Accept: application/json and Authorization: Bearer MTQ1MzE5OTg2MjYzMTo3MThjNGFiNDVmMjE4MjZiMzgxNjp0ZW5hbnQ6VGVuYW50MDF1c2VybmFtZTp0ZW5hbnRhZG1pbjAxQHZyYWRlbW8ubG9jYWxleHBpcmF0aW9uOjE0NTMyMjg2NjIwMDA6ZmJmZjU2ZmNjOTFkMDE3ODhkNjJmMzM3ZGMwMzM3NjRhMjQxNjJlMjhjMGU3YjU0YzNlZjUwYTlkYWFjNDAxYTBkODVlYzVkYWQ1YzY4ZDc0MTQ3NjBlM2Q3MDk1OGU5OTg1NjNiMTI4OWQwMGMzMzExMDAxNmEyOGY0M2MxYTk=

CreateBlueprint10

 

which should give us a response like the following, including our newly created ‘Test package’:


{
"links": [],
"content": [
{
"@type": "Package",
"id": "736562b2-c991-449a-999d-6d25f2ff05c5",
"name": "demo package",
"description": "this is the description",
"tenantId": "Tenant01",
"subtenantId": null,
"contents": [
"7e9bf69c-a4ec-44dd-98f5-6408f074a1db"
],
"createdDate": "2016-01-14T15:28:26.323Z",
"lastUpdated": "2016-01-14T15:28:26.323Z",
"version": 0
},
{
"@type": "Package",
"id": "339aeb0d-a15a-4ee1-84b7-87389d05c428",
"name": "demo package 2",
"description": "demo package 2",
"tenantId": "Tenant01",
"subtenantId": null,
"contents": [
"241fe601-5f15-4749-a6cb-f0bfdb9c97b9",
"7e9bf69c-a4ec-44dd-98f5-6408f074a1db"
],
"createdDate": "2016-01-14T17:05:47.458Z",
"lastUpdated": "2016-01-14T17:05:47.458Z",
"version": 0
},
{
"@type": "Package",
"id": "04fb81ce-9da1-46f6-b98f-fd48e8ce0e2c",
"name": "Test package",
"description": "Test package for export",
"tenantId": "Tenant01",
"subtenantId": null,
"contents": [
"2359c8c9-1ec1-4162-a9e0-aa2c5121815d"
],
"createdDate": "2016-01-19T11:28:30.507Z",
"lastUpdated": "2016-01-19T11:28:30.507Z",
"version": 0
}
],
"metadata": {
"size": 20,
"totalElements": 3,
"totalPages": 1,
"number": 1,
"offset": 0
}
}

CreateBlueprint11

 

Export the Content Package to a Zip File

Now we want to export the Content Package to a zip file so that we can have a look at the YAML file that details the blueprint:

URL: https://vraapliance.fqdn/content-management-service/api/packages/packageid

Type: GET

Headers: Accept: application/zip and Authorization: Bearer MTQ1MzE5OTg2MjYzMTo3MThjNGFiNDVmMjE4MjZiMzgxNjp0ZW5hbnQ6VGVuYW50MDF1c2VybmFtZTp0ZW5hbnRhZG1pbjAxQHZyYWRlbW8ubG9jYWxleHBpcmF0aW9uOjE0NTMyMjg2NjIwMDA6ZmJmZjU2ZmNjOTFkMDE3ODhkNjJmMzM3ZGMwMzM3NjRhMjQxNjJlMjhjMGU3YjU0YzNlZjUwYTlkYWFjNDAxYTBkODVlYzVkYWQ1YzY4ZDc0MTQ3NjBlM2Q3MDk1OGU5OTg1NjNiMTI4OWQwMGMzMzExMDAxNmEyOGY0M2MxYTk=

CreateBlueprint12

This time in Postman click on Send and download

CreateBlueprint13

This will prompt us where to save the package and what to call it; make sure you create a zip file…

CreateBlueprint14

Have a look inside the zip file and you will see the following structure; a metadata.yaml file and a composite-blueprint folder containing individual yaml files for each blueprint that was part of the package:

CreateBlueprint15

CreateBlueprint16

The contents of each YAML file are listed here for reference:

metadata.yaml


name: "Test package"
productVersion: "7.0.0-SNAPSHOT"
data:
- locator: "composite-blueprint/CentosSmall-12345.yaml"
name: "Centos - Small"
description: "Centos - Small"
exportTime: "2016-01-19T11:46:13.614Z"

CentosSmall-12345.yaml


id: CentosSmall-12345
name: Centos - Small
description: Centos Small - 1 vCPU - 1GB RAM
status: PUBLISHED
components:
Tenant01:
type: Infrastructure.Network.Network.Existing
data:
name:
fixed: Tenant01
network_profile:
fixed: Tenant01
vSphere_Machine_1:
type: Infrastructure.CatalogItem.Machine.Virtual.vSphere
data:
_cluster:
fixed: 1
min: 1
action:
fixed: FullClone
allow_storage_policies:
fixed: false
blueprint_type:
fixed: '1'
cpu:
fixed: 1
min: 1
disks:
- capacity: 16
id: 1452533069864
initial_location: ''
is_clone: true
label: Hard disk 1
storage_reservation_policy: ''
userCreated: false
volumeId: 0
display_location:
fixed: false
machine_prefix:
fixed:
id: Tenant01
max_network_adapters: {}
max_volumes: {}
memory:
default: 1024
max: 1024
min: 1024
nics:
- address: ''
assignment_type: Static
id: 0
load_balancing: ''
network: ${_resource~Tenant01}
network_profile: Tenant01
provisioning_workflow:
fixed:
id: CloneWorkflow
label: CloneWorkflow
security_groups: []
security_tags: []
source_machine:
fixed:
id: 51784cf9-fc3a-4939-abf7-2e2965523036
label: template-centos06b
source_machine_name:
fixed: template-centos06b
storage:
default: 16
max: 40
min: 16
layout:
Tenant01: 0,0
vSphere_Machine_1: 1,0

 

Create Blueprints from Postman

We can now manipulate the YAML files to create Blueprints back in vRA. Say for instance we want to add Centos-Medium and Centos-Large Blueprints. All we need to do is create additional YAML files for those two templates, update the metadata.yaml file and send back to vRA.

So the composite-blueprint folder now looks like this:

CreateBlueprint17

And the metadata.yaml file has been updated to contain the new files:


name: "Test package"
productVersion: "7.0.0-SNAPSHOT"
data:
- locator: "composite-blueprint/CentosSmall-12345.yaml"
name: "Centos - Small"
description: "Centos - Small"
- locator: "composite-blueprint/CentosMedium-12345.yaml"
name: "Centos - Medium"
description: "Centos - Medium"
- locator: "composite-blueprint/CentosLarge-12345.yaml"
name: "Centos -Large"
description: "Centos - Large"
exportTime: "2016-01-19T11:46:13.614Z"

We then create a new zip file with the updated content:

CreateBlueprint18

To create the Blueprints in vRA we send the following REST request via Postman:

URL: https://vraapliance.fqdn/content-management-service/api/packages

Type: POST

Headers: Accept: application/zip,  and Authorization: Bearer MTQ1MzE5OTg2MjYzMTo3MThjNGFiNDVmMjE4MjZiMzgxNjp0ZW5hbnQ6VGVuYW50MDF1c2VybmFtZTp0ZW5hbnRhZG1pbjAxQHZyYWRlbW8ubG9jYWxleHBpcmF0aW9uOjE0NTMyMjg2NjIwMDA6ZmJmZjU2ZmNjOTFkMDE3ODhkNjJmMzM3ZGMwMzM3NjRhMjQxNjJlMjhjMGU3YjU0YzNlZjUwYTlkYWFjNDAxYTBkODVlYzVkYWQ1YzY4ZDc0MTQ3NjBlM2Q3MDk1OGU5OTg1NjNiMTI4OWQwMGMzMzExMDAxNmEyOGY0M2MxYTk=

Body: set to form data and select the TestPackageUpdated.zip file

CreateBlueprint19

CreateBlueprint20

We should receive a 200 OK response with details of Blueprints created:


{
"operationType": "IMPORT",
"operationStatus": "WARNING",
"operationResults": [
{
"contentId": "CentosMedium-12345",
"contentName": "Centos - Medium",
"contentTypeId": "composite-blueprint",
"operationStatus": "SUCCESS",
"messages": null,
"operationErrors": null
},
{
"contentId": "CentosLarge-12345",
"contentName": "Centos -Large",
"contentTypeId": "composite-blueprint",
"operationStatus": "SUCCESS",
"messages": null,
"operationErrors": null
},
{
"contentId": "CentosSmall-12345",
"contentName": "Centos - Small",
"contentTypeId": "composite-blueprint",
"operationStatus": "WARNING",
"messages": [
"Found matching content, import will overwrite this content."
],
"operationErrors": null
}
]
}

CreateBlueprint21

Now login to vRA and you will see the three Blueprints:

CreateBlueprint22

and if we look at the details of the medium template it is showing additional vCPU and RAM resource that were specified in the YAML file:

CreateBlueprint23

Obviously, there are many other changes that could be made within the YAML file to make different templates.

Create Blueprints from vRO

While researching this topic I initially looked at a similar approach to the above with Postman when moving on to do the same for vRO. However, looking at the updated vRA 7 plugin for vRO showed a folder of workflows for working with Composite Blueprints:

CreateBlueprint24

Rather than try and re-invent the wheel I decided to see what these could do, specifically the Import a composite blueprint workflow. It has inputs of a vCACCAFE:VCACHost and a MimeAttachement, so is pretty straightforward to use:

CreateBlueprint25

Thinking slightly further ahead, rather than just run this single workflow, I would more likely use this as part of a vRA Tenant Creation workflow and would store multiple YAML files within Resource Elements and possibly update them on the fly before using them to create Blueprints. For this example though I have stored one for CentosXLarge in a Resource Element to illustrate the possibility. This is exactly the same type of YAML file for a Blueprint used in the above example with Postman, just has different values for id, name, vCPU and memory to make it XLarge:

CreateBlueprint26

So we then make a top-level workflow with two elements; a scriptable task to retrieve the YAML file from a resource element and the built-in Import a composite blueprint workflow:

CreateBlueprint27The scriptable task has an input of a Resource Element and outputs a MimeAttachment (in a more realistic example we would take and input of maybe a folder of Resource Elements and output an array of MimeAttachments). Then a simple one-liner to convert between the two object types:


var yamlMimeAttachment = yamlResourceElement.getContentAsMimeAttachment()

CreateBlueprint28

CreateBlueprint29

CreateBlueprint30

Now we can pass this MimeAttachement into the Import a composite blueprint workflow and set the vCACHost to be the host for the required vRA Tenant. From this workflow it will output the BlueprintId:

CreateBlueprint31

CreateBlueprint32

So we are ready to run the top level workflow. Specify a vCACHost and a YAML file in a ResourceElement and run the workflow:

CreateBlueprint33

Hopefully a successful run:

CreateBlueprint34

and here’s the Centos – XLarge Blueprint:

CreateBlueprint35

CreateBlueprint36

 

 

Issues with Chromecast v1 connecting to Virgin Media Super Hub 2ac

Recently got an upgrade of the Virgin Media Super Hub to the 2ac version. While making sure everything still connected OK, I was unable to connect a Chromecast v1 to the wireless access point.Chromecast

Compared to the previous Virgin Media router I had, this one has separate configuration areas for 2.4GHz and 5GHz wireless. A bit of messing around with trying to connect the Chromecast to either 2.4GHz and 5GHz wireless appeared fruitless until I dropped down the Wireless Mode setting from the default of up to 144Mbps to up to 54Mbps.

SuperHub01

Thinking back on it, I’m pretty sure that it was what the previous Virgin Media router was set to. Hence the reason I hadn’t seen the issue when first configuring the Chromecast a while back. Hopefully this blog post will remind me what I need to do next time I get an upgrade.