vCO - VMware LabManager migration to vCloud Director (part 1)

Awaiting my new hardware for testing the vLM to vCD migration I decided to give you an theoretical overview how the migration is realized. First thing I had to learn was that a vCD registered host could not act as an vLM host because of a higher agent version on the host (version 5). Unfortunately I forgot to make a screenshot (will repeat that with the new lab).

With this knowledge there is only one option: vLM with vCenter Server 4 and vCD with vCenter Server 5, both registered in the vCenter Orchestrator.

When migrating to vSphere 5 this could be a one-time scenario. Maybe there are two environments -> the "old" vSphere 4 with vCenter Server 4.x, ESX/ESXi 4.x and VMware LabManager 4.x.x and the "new" one with vCenter 5, ESX 5 and vCD 1.x.

The migration scenario I want to build up is divided into the following steps:

1. Archiving the vLM VMs into the Library
2. Export of the archived VMs to a "transfer" NFS datastore
3. Creation of the "old" configuration as vApp in the vCD
4. Import of the exported vLM VMs as new vCD VMs

Really simple, or what?

I think I will need several SOAP workflows for the vLM to export the VMs in a consistent state to the "transfer" datastore. Next thing is to create the configuration in the vCD and register the VMs as new vApps or VMs in the vCD. 

Please be patient, in the next 2 weeks I will test it and create a manual for the migration including the vCO packages.

In the meantime... have a look upon the new AMQP Plug-In!

vCO - what´s up with VcOptionValue?

Based on my article about the fixed VM boot order and the used VcOptionValue I investigate some time to figure out what else we can do with these parameters. The main statement in my opinion is: "It is the .vmx extension as API data object.".

As described in the API reference: OptionValue we know that there are two properties: key and value, as used in many other objects.

The things which aren´t described are the keys and the values :( The thing I know from the powershell scripts was the "bios.bootDeviceClasses" key in my last article: VM Boot order.

After some investigation I found several other keys and values described by Ulli Hankeln at:

http://sanbarrow.com/vmx/vmx-advanced.html

With the knowledge of these parameters it is really easy to automate your .vmx parameters. Especially the uuid parameters ("I copied this VM"), could make your life easier.

Here is one example to automate the KB196 change (repeated characters in VM console) which comes up very often in Linux-VMs:

Please find the .package file for download at google-docs:

  de.cjohannen.local.KB196.package

If you have use-cases, please let me know how you change the rules :)