I just want to make sure I'm on the right track here. I'm working on a workflow that will kickoff during MachineProvisioned stub to change the dvsportgroup. I brought in a get virtual machine by name at the beginning of the workflow which then converts the array to a vc:virtualmachine and pass that on. Is this the best way to get the VM name for the workflow to automatically run?
Is it possible to run this during building? I have a workflow that names my machine. Maybe if I put a wait in place to allow the VM to finish cloning then change the dvsportgroup?
Ok, so you don't need to use the VC:VirtualMachine object. There's a vCO workflow called "Create/Update Property on VirtualMachine Entity" in the Extensibility/Helpers folder in vCO. You can use this to set the VirtualMachine.Network0.Name property during the BuildingMachine workflow.
The workflow takes a VCAC:Entity object as an input parameter, so if you're calling this from the workflow stub, you don't need to switch the vCO object type, it should just work. My workflow is attached, if it helps.
I've tried exporting and importing the workflow and it's working for me... Are you doing the import from a vCO folder, or with the Package Import tool?
My workflow has 2 components.
1. A script task - this gets the value of the VirtualMachine.Network0.ProfileName property (which the user chooses when selecting the blueprint). It then uses the value of that property to select which dvSwitch port group the machine will end up on.
The second component is the "Create/Update Property on VirtualMachine Entity" workflow, which takes the networkName parameter from the previous script, and sets the VirtualMachine.Network0.Name value accordingly.
I think maybe I'm going through this the wrong way from the looks of your workflow. Yours defintely helps, but for my workflow we start by just getting the vc:virtualmachine name. I think we should probably be requesting the vcac:entity and output would be the vc:virtualmachine correct?
Basically what happened is we do have a workflow setup to change the network already.(although your solution seems easier had we started with it ). When we added that to the machineprovisioned stub, it changed a different VM's network in vCenter and not the network on the VM it should have ran on. I just want to make sure I'm calling the right inputs/outputs so i'm not messing anything else up running in our environment.
Yeah, I feel your pain. I had a lot of fun getting this to work.
If you're calling a workflow stub to a vCO workflow, as I understand it, the input parameter to vCO will always be VCAC:Entity. As you've probably begun to see, it can be tricky to get the right object type from there (ie: vCAC:Entity to VCAC:VirtualMachine and then VC:VirtualMachine).
This is why I ended up with the workflow I have. It's much easier to stay within the bounds of the VCAC:Entity object type, and for the most part vCO has the workflows to help make the changes to the VCAC properties as required. This is of course dependent on the vCO workflow being called from BuildingMachine, and not MachineProvisoned.
I'd be happy to cast an eye over your workflow if it would help?
Ok, I think the problem is your input parameter "criteria". I don't see how that is getting set. I'm guessing that if you convert 'Criteria' to an attribute, and set it yourself, the workflow will work on it's own (calling it manually in vCO.)
So far, as far as I can tell, the default input parameter to a vCO workflow from the VCAC stub is VCAC:Entity. You kind of have to work from there. So for your first script to work, you'd need to have an input parameter type of VCAC:Entity, and then do something to work out which VC:VirtualMachine corresponds to it.
There's a downloadable "Action" I found which does just that. Grab the package linked in this thread: Re: get vCenter VM from vCAC VM
This action takes a VCAC:VirtualMachine type as an input, so you'll need to go from VCAC:Entity to VCAC:VirtualMachine, I haven't worked out how to do that yet, but I'm sure it's possible somehow...
### Edit ###
If you look at my first script, that code effectively gets cycles through all the properties of the VM from a VCAC:Entity viewpoint. The first variable gets set to the MachineName, so you should be able to create a new variable from that, which will be of type VC:VirtualMachine.
Hope this points you in the right direction...!
Here's a fun fact... when you're performing state workflows, vCO will actually pass in a lot of these values.. You just need to have them defined in the master workflow you're using. Under Library -> vCloud Automation Center -> Infrastructure Administration -> Extensibility, you'll find a workflow called "Workflow Template".. You should use that as a starting point for all of your state workflows. Any objects you're not needing for the state, you can remove after the fact, but it'll give you something to work with. The great thing is that the vCAC Entity will always get passed in this way, since the workflow runners capture and pass it in. For my own particular uses, I use the vCAC entity (a lot) during building state to take values I set for provisioning during that state prior to the VM being created. Then, during provisioned state, I use both the entity (when I need to update something) and the VM object from vCenter. The state workflow passes these in, meaning absolutely 0 effort on my part. It avoids a lot of pain and suffering of having to do work that's already been done for you.
In my opinion, you're 200x better off updating the network name in vCAC during the building state, if you can resolve the name properly at that point (I just went through the pain of figuring out a more dynamic way to do this, given some environmental... issues), so I can attest how unpleasant it can be. However, doing it at this point means consistency between vCenter and vCAC. If you make the change during provisioned state, you have to wait for the next data collection cycle for vCAC to recognize that the network name was changed in vCenter.. That may not be an issue, per se.. but, 24 hours is a long time (in my opinion) to wait for that to reconcile.