Latest Headlines

SRM and the planned migrations…..

Be aware, this post has nothing to do with Automation or Orchestration. This post is only related to the VMware Site Recovery Manager and a solution for a Problem during a planned migration. Maybe the post is useful for someone else which encounters the same problems…..

Last weekend I supported a customer witch had to power down one of his both datacenter. For this, we had to migrate the virtual Machines from one DC in the other. At the end all machines must be migrated back. From my site a view, this should be an easy thing because the customer had an SRM implementation. The storage is served via an IBM V7000 and the LUNs are replicated over both datacenter….. The customer had built the recovery Plans and tested them before the Migration should occur…

So from my point of view I expected an easy migration……

After everything was cleared the users were at home we started with a “Planned Migration” from the Datacenter 1 (DC1) to Datacenter 2 (DC2). This was quite easy and at the end we created our “Failback Plan” with the SRM.

No for us it was time to take a drink and wait for the Power and Air-conditions Guys to finish their jobs.

After a few hours it was time for us to migrate the VMs back to DC1…….

The customer created a recovery plan for his two different clusters. In the first cluster only the normal VMs were placed. In the second cluster the Database VMs were located…..

So we started the planned and the VMs out of the first Cluster fail back without any problems…..sincerely the VMs from the Database Cluster could be relocated……

We got the error:  No host with hardware version ‘9’ and datastore ‘snap-ef732565ae’ which are powered on and not in maintenance mode are available….

So we checked the vSphere client…..the Hosts were online (Host Version 5.5) and the Datastore with the name ‘snap-ef732565ae’ was also present…..

Really strange……a quick search in the Web leads to this VMware Documentation ( were the problem was described with the solution to wait 15 Minutes for the next try because the SRM had cached some old information. So we took a coffee break  and after 20 Minutes we started the next try……unfortunately we had the same problems……

I tried to figure out the problem in the logs but I could found anything what pointed to the error…..

So we tried a lot of things to finish our “Planned Migration”…..every try needed a lot of time……one of the last things we did was to restart all ESX Hosts of the DB Cluster…..after all Hosts were Online we did the next try and “voila” I worked……

In the last week I did a lot of research about this behavior.  I figured out that I could reproduce the error when I power-up the ESXi Server quickly without any delay.  So from my point of view it seems to be a “communication” problem between the ESX Hosts of a cluster.


So if anyone has the same problem….try a reboot of the ESX Hosts……


Wavemaker and vCO – The next level

Remember these?

Well, it has been quite a while since then, and a lot happened to Wavemaker in between: 

This week VMware released a new Fling: “Wavemaker Integration with vCenter Orchestrator”

This fling allows you to:

  • Run the included WaveOperator demo project, that provides common tasks (like start and monitor workflow execution), comparable to the weboperator webview in vCO
  • Use the widgets to create your own web interface for your workflows
  • Use the Java Services that expose the vCO API into Wavemaker projects

Sounds cool? Is cool! No more manual getting things together, but predefined wavemaker widgets for your workflows to just drag and drop into yourweb interface!

But wait, there’s more! The project is available open source on Github:

So you can even expand the functionality to your needs, or adopt the code for your projects.


vCO Input Presentation

Last week I received a customer question regarding a vCO input presentation. The customer has a vCO Server were multiple vCenter Servers are connected. For his environment, he created a workflow were users are asked to give some information. Based on this information the view should be restricted.

First thing the customer had, was a Variable from type VC:SDKConnection. This is used to choose the correct vCenter Server.

When you start a vCO Client with this, you can pick the right vCenter Server for your need.

The next thing what should be archived was the possibility, to pick an ESX Host from that vCenter Server. As I looked into the customer configuration I saw that there was a  created  “Select value as” and “Specify a root object to be shown…:”

With this config the view was not as the customer was expecting it. When the user came to the point to  choose an ESX Host, the users saw all ESX Server from the hosts.

This is really uncool…..

So how can we fix this behavior?

That’s pretty easy…..

Let’s go back to the Workflow. There we choose the Presentation pane and the input. Then we change the  “Specify a root object….”

Here we change the Value over the Pen (in this case) to #vCenterServer.

When we now save the workflow and start it again wen only see the Hosts / vCenter Server to which we limited the view.

Easy or?

One important note here: The limitation of the View works only with the “Select value as” tree. It doesn’t work for the other views!

So have fun and orchestrate the World!


Must read for all vCO workflow developers

“Lessons in Software Reliability” is an article recently published on It gives some very valid and valuable tips for “What does it take to build reliable and stable enterprise software?”.

The content not only applies to to software development, but also to workflow development in vCO. You do want your workflow to be reliable, aren’t you?

Here’s the link:


Automating Veeam with vCO and the Restful API

Do some of you remember my Blog Post about automating Veeam with vCO and Powershell ( The problem at this time was that Veeam only offers a PowerShell API. Now, some time is gone and Veeam released the Version 7 of Backup&Replication.  In this Version, Veeam offers an Enterprise Manager which offers a Restful API for automating.  Please be aware that the Restful API is only available in the Enterprise Plus Version of Veeam B&R.  The Veeam Restful API can be accessed over this URLs and ports:

Veeam Restful API HTTP URL  http://<Enterprise-Manager>:9399/api/

Veeam Restful API HTTPS URL https://<Enterprise-Manager>:9398/api/  

A comparison can be found here: So, let’s start with the integration. First think what we have to do is to connect the vCO and the Veeam B&R server. Therefore we need the vCO Rest Plugin which must be installed over the vCO Plugin page. Details how to do install a plugin can be found in the vCO Documentation for the Plugin (

After we have installed the Plugin, we can connect the vCO and the Veeam Server. Therefore we have a build in Workflow “Add a Rest Host”

In the Workflow we have to give our Restful Host a Name and have to define the URL. The settings for the Connection and Operation timeout doesn’t have to be changed.

The Authentication for the B&R Server has to set to Basic

The next thing is to chose a Session mode. You can chose between a “Shared Session” and a “per User Session”. Which you chose depends on your security settings. I will take a shared Session in the Screen-Shots. For the shared session you have to define a user and a password.

If you use a HTTPS connection, you have to accept the SSL Certificate for the B&R Server.

At the end you start the Workflow and if everything goes well, your Workflow finished without any problems.


The next thing you can do, is to import the Veeam Rest Schema. The Schema is located in the Path “C:\Program Files\Veeam\Backup and Replication\Enterprise Manager\schemas\RestAPI.xsd” on you B&R Server. To import the file, you have to transfer it to a Webserver so that the vCO Server can import the schema. To start the import we start the Workflow “Add schema to REST Host”. 

In the Workflow, we have to change the REST Host to which we want import the schema.

In the next screen we have to define the Web URL were the schema file is located.

If everything goes well, your workflow finished without any error and the Schema is available under the Rest Host.