Tag Archives: ORchestrator

vRealize Orchestrator 7 Release

As you’re probably aware by now VMware released vRealize Automation 7 today. I already discussed vRA 7 before and there are a lot of blogs out there writing about it.

What I didn’t blog about before is that with vRA7 VMware also released vRealize Orchestrator 7.  Since vRO is the magic sauce that makes vRA work anyways I’m far more interested in the vRO release. So I quickly downloaded the ova (yep, no windows installer anymore), imported the ova into VMware workstation and connected to it. All in under 7 minutes :).

I read on another blog that there now is an HTML 5 client. But nope…. only the control center is HTML5.  The client used to develop workflows is still the same Java contraption. But it supports reconnecting now. Which is very nice because that means you don’t loose any work when a vRO server stops responding. Other than that I couldn’t find any improvements in the client. Still no decent IDE like environment to write your scripts in, no improvements to the api explorer as far as I can see. I’ll digg deeper in the coming week and let you know what I find.

Other new features:

  • Centralized Server administration.
  • Easy cluster configuration.
  • Easy workflow troubleshooting and runtime metrics.
  • Enhanced log monitoring, log persistency and added ability to export logs for a particular workflow run.
  • Direct correlation of system properties and workflow performance through the embedded JMX console integration.
  • Significant Orchestrator client improvements, including a workflow tagging UI, client reconnect options and enhanced search capabilities.

VMworld and the future of Orchestrator

Last week I attended VMworld Europe in Barcelona. I had a great time, eating tapas, drinking Rioja and learning something new in between. I already wrote about elasticity achieved using project fargo and docker on my company blog. Since this blog is more automation focussed I wanted to highlight some automation news. OR actually it is more about the future of Orchestrator.

The first thing that stood out to me was the lack of vCenter Orchestrator uuhh vRealize Orchestrator break-out sessions. I think there were two or three session explicitly about Orchestrator. A couple others went a little bit into orchestrator but were focused on vRealize Automation (vCAC). Last year there were quite a couple of sessions about Orchestrator. Telling us it was the best kept secret or the best VMware product never released and we should really go and use this awesome tool. And of course they were right to say so. And seeing where VMware is going with Orchestrator I was really surprised they didn’t give it more attention during Vmworld.

Which brings me to my second point. It is clear by now that Orchestrator will be used as the back-end for vRealize Automation. We can already see this in the current versions: The integration with NSX is completely implemented using Orchestrator. vCAC ugh… vRA has no interaction with NSX whatsoever, everything is handled via Orchestrator.

The same goes for what VMware calls Anything as a Service. Which is delivered using the Advanced Services Designer. Yeah that’s a lot of buzzwords in one sentence. In reality it is just a forms designer which you can use to design user front-ends for Orchestrator workflows. The objects created by the workflow can then be managed by vRealize Automation.

I already see that the adoption of Orchestrator is mainly driven by the use of vCAC. But there is more to come. VMware told in one of the Orchestrator sessions that Orchestrator will be used as a DEM replacement for vRealize Automation (but any information given in such presentation may change at any time). For who isn’t familiar with vCAC/vRA; The DEM is the Distributed Execution Manager. It is basically the component which does the actual work in a vCAC deployment. Currently it is 100% .net code and runs MS .NET workflow foundation workflows. So it makes total sense to replace that workflow engine with VMwares own workflow engine. The result will be that some day we can get rid of the windows components in vCAC and end up with just a virtual appliance which is easy to deploy and configure. That day will be a good day.

To be able to use orchestrator on the scale that vRA requires there will be some changes to the product in the future. For example, better permission management, multi geographical deployment models, integration with DevOps solutions and a lot more.

So although Orchestrator didn’t get a lot of attention during VMworld it seems it is going to play a crucial role in VMware’s automation strategy. Nice 🙂

Meet the Automate-IT Robot

Time for a less serious friday afternoon post. Meet our new friend: The Automate-IT Robot a.k.a. r2vco2. It’s a robotic arm with a special feature: It can be controlled by vCenter Orchestrator.

Robotic Arm

When I was preparing for the yearly ITQ Technical update session I was thinking of a way to show vCenter Orchestrator can do much more then just automating vSphere tasks. What better way to show this that control something physical from a tool that’s usually used in the virtual world? So I decided to try and build a robotic arm.

The Bones

The bones of the arm are 3d printed using an Ultimaker Original. Of course the type of printer isn’t that interesting. But what is interesting are the 3d models I used. Thanks to thingiverse it only took me a few minutes to find a 3d printable robotic arm. I also foudn some modifications to the original design which I ended up using. Here a the links to the different projects I used:

I recommend using the openSCAD version of the design. I initially used parts of the original design but the gripper didn’t work for me. So I replaced the top arm and the gripper for the openSCAD parts. Also I needed stronger servos for rotation and the lower arm so I used the parts modified for MG995 servos. So the only part I used from the original thingiverse project is the middle part of the arm.

Gripper

The Muscles

The robot’s muscles consist of  5 hobby servos. Those are the same kind found in RC cars and airplanes. For the rotation and the lower arm I used the TowerPro MG995. You can find them on e-bay for a few bucks. The other servos are the very small 9g servos. This means that they weight only 9 grams which is a good thing considering they have to be lifted by the lower servos. Oh, and you;ll find them really cheap on e-bay as well.

All the servos can draw a considerable amount of power from the power. A little over 3 Amps if all motors are at full power. This cannot be supplied by a micro controller or a USB port so I build a simple power supply. It consists of just one voltage regultor  (LM123K) and two tiny capacitors. The LM123 converts 12 volts down to 5 volt and can deliver up two 3 Amps. It doesn’t need cooling to do this and the thing turned out to be fool proof. I hooked it up the wrong way a few time but it still lives.

Voltage regulator on top of Arduino Yun
Voltage regulator on top of Arduino Yun

The Brain

An Arduino Yun is the physical part of the robot’s brain. The Yun is a development board that has an AVR micro controller and an SoC running openWRT in one package. It is equiped with LAN, WiFi and an micro SD Card slot. The cool thing is that the Linux part of the board runs a webserver which can be used from the AVR part of the board. Arduino provides a bridge library to aid communication between Linux and AVR. Using this library it is relatively easy to build a web API on top of your micro controller code. And that is exactly what I did.

The software for the brain is a rather simple sequence recorder/playback device. So I can program positions into steps which are put into a sequence. Everything is controllable via a REST like API. I used the API to create a very simple AJAX web interface which is served by the linux part of the Yun as well. But I didn’t stop there. I created a few vCO workflows which are able to control the robot. The vCO REST Plug-in makes this very easy.

I’ll write more about the software and the vCO integration in a follow up blog.