0

vRO 7.6 XaaS form support clarification

When vRealize Orchestrator 7.6 became generally available last week (and related to the simultaneous availability of vRealize Automation 7.6), an eagle-eyed VMware Partner spotted a statement in the release notes under the Feature and Support Notice section.

One of the statements in that section initially read:

vRealize Automation XAAS forms support only workflows created in the Orchestrator Legacy Client.

I asked a colleague in the Cloud Management Business Unit (CMBU) about this and was eventually put in touch with the right person in R&D who could expand on the meaning further.

The statement has now been adjusted to read:

The input parameter constraints of workflows created or edited in the vRealize Orchestrator Client do not automatically transfer to the XaaS blueprint request form in vRealize Automation. When using these workflows in XaaS operations, you must manually define the input parameters constraints in the XaaS blueprint request form. This limitation does not impact workflows created and edited exclusively in the Orchestrator Legacy Client.

It is important to note that in vRO 7.6, the term “vRealize Orchestrator Client” refers to the new HTML5 web client, whereas the term “vRealize Orchestrator Legacy Client” is used to describe the Java client that anyone used to vRO knows very well! In case you haven’t yet seen the new HTML5 client for vRO, I have a screenshot of it in my posting on the availability of vRA 7.6, and I’ll paste it here too.

Workflow schema open for editing in vRO 7.6
Workflow schema open for editing in vRO 7.6

Going back to the clarification, it means that workflows that are created / edited in the new client interface will not automatically have their presentation settings imported when adding the workflow as a XaaS blueprint or when refreshing the form design. Instead, a custom form would have to be created. The functionality is unaffected when using the legacy (Java) client.

0

New Year, New CTOA – Congratulations

CTOA logoVMware’s Office of the CTO (OCTO) runs an annual programme internally to appoint a limited number of outstanding individuals as CTO Ambassadors (CTOA). Broadly, the role of an ambassador is to help ensure a tight collaboration between VMware’s R&D and VMware’s customers.

CTO Ambassadors come from customer facing roles within VMware (such as SEs, PSO, TAMs and GSS). A good number of them are involved with, or are usually present at VMware’s customer focussed events (such as vForum, VMUGs and VMworld). With the new year comes a number of newly minted CTOAs. Whilst I can’t count myself amongst them, I’d just like to say a big, public “congratulations” to everyone that has been selected as a 2018 ambassador.

0

vRA 7 / vRO 7 REST error (java.security.cert.CertificateException)

Whilst I was with a customer recently, I hit an SSL related issue whilst trying to put together a vRO workflow to orchestrate the creation of a load-balancer configuration on a Citrix Netscaler VPX.

Adding the REST host(s) to vRO was accomplished without any issue, but when I came to use them my workflow failed with the following error:

As this vRO instance was running on a vRA appliance, my first port of call was starting the vRO Control Center service and make sure that the REST host certificates had indeed been imported in to vRO and were trusted. They were.

Looking at the certificates themselves (as I had blindly accepted them up until that point) I noticed that they were self-signed and the cause of the error became clearer. Some software solutions generate fairly weak SSL certificates by default to maintain backwards compatibility with other legacy solutions, and in some instances because it’s easier and cheaper perhaps. Some of the algorithms used to generate and / or sign these certificates are weak or have know vulnerabilities and are increasingly untrusted by default. You only have to fire up an up-to-date version of the Chrome browser and point it at something using such a certificate to see that happen – Chrome says no!

The java implementation on a vRA 7 appliance is no different, there are certain untrusted algorithms. Should you need to, you can enable them again.

  1. SSH to the vRA appliance using either the root account or an account capable of using sudo
  2. Navigate to the directory /usr/java/jre-vmware/lib/security
  3. Copy java.security to java.security.old (always take a backup!)
  4. Use vim to edit the java.security file
  5. Comment out the line jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
  6. Comment out the line jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
  7. Save the file
  8. Restart the vRO service (service vco-server restart)

I should stress that this is very much a short-term solution. The preferred solution would be to replace the SSL certificates on the problematic solution and re-enable the settings adjusted above. If that isn’t practical, use trail and error to work out which specific algorithm is causing the issue and remove only that from the setting.

0

Changing vRA ExternalWfStubs Timeouts

I saw a question on Twitter this morning that I thought warranted a quick post:

201511324_111120-CapturFilesThe default timeout for the various workflow stubs is 30 minutes, but they can be changed. As always, take backup copies and be careful! The six stubs that can be changed are:

  • Expired
  • RegisterMachine
  • Disposing
  • UnprovisionMachine
  • BuildingMachine
  • MachineProvisioned

The timeout settings for External Workflow stubs are configured on the Windows server (vRA 6.x) that hosts the Manager role. The file and path required (assuming a default installation) is:

Using your favourite text editor, simply adjust the timeout value for each workflow. Most people tend to require a longer timeout for “MachineProvisioned”, often because they require longer running post-provisioning tasks to complete before handing a Virtual Machine over to the requester.

201511324_121183-CapturFiles

Save the file and make sure that the same changes are made on the standby Manager if you have a distributed installation. You’ll also need to restart the Manager service for the change to take.

One word of warning though, extending the timeout could mean that the DEM worker(s) get clogged up with running workflows. Remember that each worker can run 15 simultaneous workflows. So if you extend the timeouts, you may need more DEM Workers. Best to monitor the number of concurrent workflows for a few days if you’re unsure.

0

Thank you Xtravirt…

It was with some sadness that I left the Xtravirt offices in Surrey for the last time recently. Due to the nature of my work I’ve rarely been there, but it always felt like home because of the people.

If, for some reason, you’re not familiar with Xtravirt, they’re a leading virtualisation and cloud consultancy whose ambition and capabilities far exceed their size. They’ve got some great consultants, many of whom I’ve known from before they were at Xtravirt, great management and the highest ratio of vExperts per employee in the world (although that might have taken a hit).

All good things (including the last 18 months of automation and orchestration work on two large-scale cloud projects) must come to an end however, so I wanted to take this opportunity to thank everyone at Xtravirt for the great times and the opportunities there. We move in fairly small circles and I’m sure our paths will cross often.

Xtravirt Logo

0

VMworld 2014 – Day 1

Tuesday in Barcelona is when things really get going. First up on everyone’s schedule is the VMworld keynote. This is one of times when attendees get to hear from Pat Gelsinger (VMware’s CEO) and a number of other presenters and get an overview of the direction in which VMware are going. It’s also when the major product announcements are officially made.

Historically, VMworld Europe is usually the time when management product updates are announced (with some of the more infrastructure based updates happening at the US conference). It’s been slightly different this year I suppose since there was no major update to the core vSphere platform, but there was EVO:RAIL.

During the keynote, announcements were made about:

Another difference that I’ve picked up on this year is that the general sessions at VMworld are now more widely available. Having watched the US conference keynotes, there was a degree of repetition. That’s not to say that I didn’t enjoy it, but it didn’t feel quite as fresh as it did in previous years to me.

After the keynote finished, and the hoards poured out of the main hall, I had a meeting with a company called ByteLife and Joerg Lew (one of VMware’s vCO gurus) about a new community initiative called FlowGrab.

FlowGrab is a new and developing community for vCO workflows and packages. There are some good things coming with regards to this project and if you’re using vCO, I’d recommend that you check it out.

I spent a while after that in the Solutions Exchange talking with representatives of a few companies whose products and services that I’m interested in. Key among those were PernixData, Colt, Atlassian and PuppetLabs.

I had two breakout sessions that I was very keen to attend and I was pleased that neither had been moved around (as has happened a few times over the years). The first of these was SEC1746 NSX Distributed Firewall DeepDive. I haven’t done a lot with NSX outside of my lab but it’s an area of great interest to me given its links to vRA (vCAC) and it position as a key component in the SDDC vision. For me it was a good session as it wasn’t all alien (or new) to me but there was plenty in there to make me think and takeaway.

Immediately afterwards I had my second session of the day, TEX1991 vCenter Orchestrator – What’s Next. I’ve worked a lot with vCO in the last year (at times, almost exclusively), so I was very keen to understand the product’s future. Once again, there were things that I knew about and some that I didn’t. I even learned a few things about version 5.5.2 that I wasn’t previously aware of.

To round out the day at the conference centre, I had a really great chat with Frank Denneman (PernixData) that has kept me thinking ever since. And I had a couple of brief chats about Xtravirt’s forthcoming beta for a new service called Sonar.

As for evening activities, they started with drinks and conversation with some of Xtravirt’s partners in the Solutions Exchange and moved on to Ocana for the vExpert / VCDX reception. As that started to wind down, I moved on to the excellent vJamon party, organised by Cisco’s @CommsNinja.

0

Are you a vExpert?

vEXPERT_2013_fakeVMware’s vExpert award isn’t something that you can study for. It’s not something that you know, it’s something that you are!

This is the 5th year that VMware have operated the the programme (“program” for any US readers) and applications for the 2013 award are open now. If you’ve contributed any of your time in 2012 to enhancing the VMware community in some way then it might be worth your while applying.