VMware Realize Orchestrator OVF Transfer Plug-In Version 3 released

I am pleased to announce a new Version of the popular OVF Transfer Plugin. The new mayor release Version is 3. My colleague Sascha Bitzer made a lot of Improvements for the plugin.

In this version we include some bugfixes and also new feature. Here are some Highlights:

The OVA/F Transfer plug-in allows you to import and export virtual machines as OVF/OVA template to/from the VMware vCenter via the VMware vCenter/vRealize Orchestrator.

This plug-in provides actions and workflows to use the OVF/A functionalities directly in

your own workflows. It also supports the automated creation of OVF/A Import Workflows, based on provided ovf/ova files.

Nowadays this plugin also supports new features like vRA-Integration, Authentication and simple File upload



This plug-in includes amongst others following features:

  • [Export] Export of virtual machines as OVF templates
  • [Import] Import of virtual machines as OVF or OVA templates
  • [Import] Automated creation of Import workflows based on OVF/A
  • [Import] Support for vSS and vDS PortGroups
  • [Import] Support for multiple vNics
  • [Import] Support for OVF properties and Deployment Options, e.g. used for virtual appliance imports
  • [Import/Export] Supported sources/destinations: Locale file, HTTP, HTTPS,FTP, CIFS
  • [Import] Import OVF/A using vCAC/vRA – Service Blueprint
  • [Import/Export] Support for Basic and Digest authentication
  • [Import] Upload of any file to datastore (e.g. ISO)



This plug-in contains two ready to use workflows for importing and exporting virtual machines. It also contains one workflow for extracting and displaying all available OVF

properties usable for the import workflow. For a wizard like experience there is also a workflow for an automated generation of import workflows based on the provided

OVF/A files. This automatically generated workflow will contain all input parameters and options for the given OVF/a file. In addition to those workflows you will now find

two new workflows. The first one is used to upload any kind of file to a target datastore.

This workflow can therefore be used to manage the upload of ISO files/images. The second workflow enables you to integrate the process of importing an OVF/A into your

vRA environment. Now it’s possible to import OVF/A directly with vRA. You can find those workflows in the Workflows folder: SVA/OvaTransfer



The Plugin can be found at the VMware Solution Exchange. Here is the URL:



Have fun and orchestrate the World 😉



Where is the Orchestrator 6.0 client installation file?

Usually you can start the Orchestrator client just via Java WebStart using the link on the welcome page of your vRO server.

However, due to several security restrictions in current Java versions, and OSX versions, that might be quite an effort to configure your system that this actually works (permanently).

In older vCO versions there were direct links to the standalone client installation downloads on the welcome page, but these links disappeared in vRO 6.0 (that comes with vRA 6.2, and the upcoming vSphere release).

So, here’s where you find the installation files: They are zipped in the file


on the appliance (it’s about 165MB!). Use for example scp to copy them to your local system (SSH has to be enabled in the appliance configuration):

scp root@your-vro-server:/usr/lib/vco/downloads/welcome-page-resources.zip .

Then you can unzip the file, and voila, find the standalone installation files…


Fixing SDKTypeConvertor_server related errors in vCenter Orchestrator 5.5.2

In vCO 5.5.2, when you get error messages “ch.dunes.vso.sdk.SDKTypeConvertor_server$1  cannot be cast to XYZ” or “Unable to serialize object of class : ch.dunes.vso.sdk.SDKTypeConvertor_server$1”, you hit a bug in the vCO platform.

This issue for example occurs if you use the vCAC Plugin, to run vCO workflows as part of vCAC lifecycle processes. Then the “workflow runner” workflow in the Library fails with the error (see screenshot)

To solve the problem, you have to install a patch, the description and the patch download you can find in the VMware KnowledgeBase:



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 (http://pubs.vmware.com/srm-55/index.jsp#com.vmware.srm.admin.doc/GUID-FE6A85EC-B44E-415A-9C5F-1E17BC846119.html) 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……


Must read for all vCO workflow developers

“Lessons in Software Reliability” is an article recently published on www.javacodegeeks.com. 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: http://www.javacodegeeks.com/2011/06/lessons-in-software-reliability.html