run VM workflow against single vcenter sdk connection

[jauling]

Hi everyone,

I'm running vCO 5.5.1 appliance, connected to 13 vCenters spread around the world. Yea I know, probably not the best idea, but it does seem to work fine. We aren't really in a position to re-architect to take advantage of cluster mode at the moment...

Anyway, with that many vCenter connections to vCO, even simple VM operations are taking quite a long time. This is due mostly to the fact that even simple workflows that start/stop VMs seem to rely on querying ALL the SDK connections in vCO. We provide a VM name (or UUID) as input, and vCO then queries all our vCenters until it can return a VC:VirtualMachine object, which is then used as the real input parameter to execute the VM-related workflows in question.

Does anyone know of a more effective/efficient way to have vCO retrieve the VC:VirtualMachine object, instead of iterating over all the SDK connections?

[cdecanini_ · Accepted solution]

From where do you start the workflow ?

Getting VM by name is bad practice, particularly if you have many vCenters / VMs.

vCO has a nice tree view inventory allowing to load in the inventory only the objects under the containers (VM folders, resource pools) you select.

If you use an external system that does not know how to interface with vCO API to get the tree view you should get the VMs per their ID.

You can start a vCO workflow passing as input the object ID (either vCO unique one or object type + object ID + vcenter host) doing:

var moRef = new VcManagedObjectReference();

moRef.type = ref.type;

moRef.value = ref.id;

vcObject =  VcPlugin.convertToVimManagedObject(vimHost ,moRef);

[jauling]

We disabled the inventory service back when we were on vCO 5.0, due to some instability issues. I'm not sure if that was ever resolved? Sorry, not trying to take this thread off on a tangent.

The code snippet you posted looks like what I'm after, especially with the vcenter host param, assuming it doesnt depend on the inventory service?

[cdecanini_]

It does not depend on the inventory service.