I've got a simple workflow setup that runs another (svmotion) workflow. Once the svmotion completes, the original workflow uses wfToken.getInputParameters().get("vmToMigrate"), to determine the VM that was migrated. However, I'm having a problem with the consistency of what goes in / comes out.
what is given to the svmotion workflow:
Have you restarted the vCO service ?
I always used share a unique session here and never had this issue so I am suspecting a problem with session per user.
Also what is your vCenter build ?
Hi Deric,
could you please provide code or snippet? Best practice is to share a package.
Regards, Andreas
Sure, here is an example package with example output:
Thanks,
Deric
Cannot reproduce here:
[2011-03-24 15:23:30.495] [I] Primary workflow vm: DynamicWrapper (Instance) : [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine] -- VALUE : VirtualMachine<vm-1122>'New Virtual Machine 2'
[2011-03-24 15:23:30.497] [I] Primary workflow vm.id: vm-1122
[2011-03-24 15:23:30.497] [I] Primary workflow vm.name: New Virtual Machine 2
[2011-03-24 15:23:30.625] [I] Primary workflow vm: DynamicWrapper (Instance) : [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine] -- VALUE : VirtualMachine<vm-1122>'New Virtual Machine 2'
[2011-03-24 15:23:30.626] [I] Primary workflow vm.id: vm-1122
[2011-03-24 15:23:30.627] [I] Primary workflow vm.name: New Virtual Machine 2
Try this: replace the start workflow in parallel by a nested workflow and tell us if it changes anything.
Christophe.
I'm not sure how to access the workflow tokens of nested workflows...
Out of curiousity what version are you running? We're on Server / Application 4.1.1 build 733
Thanks,
Deric
You are right about the nested workflow would complicate the task of finding the second workflow. I am on 4.1.0 build 581.
When you check the variables tab of the secondary workflow execution / run, do you see the name of the vm or not ?
Christophe.
yes, and the secondary workflow logs the following:
[2011-03-24 11:06:34.117] [I] Secondary workflow vm: DynamicWrapper (Instance) : [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine] -- VALUE : VirtualMachine<vm-1514>'testVM01'
Thanks,
Deric
Really odd. Do you have a null for the vm name everytime ? Have you played with the timing. Maybe I have a slower server and things do not happen in the same order.
Yes, everytime. I've played with the timing some including checking the state of the workflow token.
Try this attached updated package. I see the following log:
Thanks,
Deric
It failed since you call sleep without "System." If you did not notice this it means in your case the secondary wf has already completed (you have a faster system) or has no status yet (you have a dog slow system)
I corrected the System.sleep and got:
[2011-03-24 16:36:30.981] [I] Primary workflow vm: DynamicWrapper (Instance) : [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine] -- VALUE : VirtualMachine<vm-1122>'New Virtual Machine 2'
[2011-03-24 16:36:30.982] [I] Primary workflow vm.id: vm-1122
[2011-03-24 16:36:30.982] [I] Primary workflow vm.name: New Virtual Machine 2
[2011-03-24 16:36:31.064] [I] wfToken.state: running
[2011-03-24 16:36:31.115] [I] Primary workflow vm: DynamicWrapper (Instance) : [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine] -- VALUE : VirtualMachine<vm-1122>'New Virtual Machine 2'
[2011-03-24 16:36:31.116] [I] Primary workflow vm.id: vm-1122
[2011-03-24 16:36:31.116] [I] Primary workflow vm.name: New Virtual Machine 2
[2011-03-24 16:36:32.131] [I] wfToken.state: completed
[2011-03-24 16:36:32.134] [I] Primary workflow vm: DynamicWrapper (Instance) : [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine] -- VALUE : VirtualMachine<vm-1122>'New Virtual Machine 2'
[2011-03-24 16:36:32.135] [I] Primary workflow vm.id: vm-1122
[2011-03-24 16:36:32.135] [I] Primary workflow vm.name: New Virtual Machine 2
Thanks for the correction. I've fixed the sleep in the primary workflow and added a 5 second sleep to the secondary workflow to make sure I catch it while it is still running. Doesn't seem to make a difference.
[2011-03-24 13:25:56.704] [I] Primary workflow vm: DynamicWrapper (Instance) : [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine] -- VALUE : VirtualMachine<vm-1514>'testVM01'
[2011-03-24 13:25:56.704] [I] Primary workflow vm.id: vm-1514
[2011-03-24 13:25:56.704] [I] Primary workflow vm.name: testVM01
[2011-03-24 13:25:56.829] [I] wfToken.state: running
[2011-03-24 13:25:56.845] [I] Primary workflow vm: DynamicWrapper (Instance) : [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine] -- VALUE : VirtualMachine<vm-1514>
[2011-03-24 13:25:56.845] [I] Primary workflow vm.id: vm-1514
[2011-03-24 13:25:57.157] [I] Primary workflow vm.name: null
[2011-03-24 13:25:57.157] [I] wfToken.state: running - sleeping 1 second.
[2011-03-24 13:25:58.157] [I] wfToken.state: running - sleeping 1 second.
[2011-03-24 13:25:59.157] [I] wfToken.state: running - sleeping 1 second.
[2011-03-24 13:26:00.157] [I] wfToken.state: running - sleeping 1 second.
[2011-03-24 13:26:01.157] [I] wfToken.state: running - sleeping 1 second.
[2011-03-24 13:26:02.157] [I] wfToken.state: completed
[2011-03-24 13:26:02.157] [I] Primary workflow vm: DynamicWrapper (Instance) : [VcVirtualMachine]-[class com.vmware.vmo.plugin.vi4.model.VimVirtualMachine] -- VALUE : VirtualMachine<vm-1514>
[2011-03-24 13:26:02.157] [I] Primary workflow vm.id: vm-1514
[2011-03-24 13:26:02.407] [I] Primary workflow vm.name: null
Any other thoughts?
Thanks,
Deric
Maybe putting the server in debug mode and checking the logs for something suspicious.
It is weird you get the id and not the name.
good suggestion... actually didn't even need to turn it up to debug, it was already spitting out errors, although, I'm not sure the culprit.
2011-03-24 13:19:45.550-0400 INFO [Execution] Executing workflow 'primaryWorkflow'
The user used for vCenter is the one you configured in the plug-in, not the one you configured as part of vCO Admin (this one is used to check your permissions for doing things in vCO).
This seem similar to the error in this thread
Are you using shared sessing in the plug-in or session per user ? If the second one switch to the first one and try again.
It was set to "Session per user" and I switched it to "Share a unique session" using either my account or the service account we have setup. Same thing.
Have you restarted the vCO service ?
I always used share a unique session here and never had this issue so I am suspecting a problem with session per user.
Also what is your vCenter build ?
Have not restarted the vCO service, but I have removed / readded that vc and changed the session options.
vCenter is 4.1.0, 345043
While the vCenter plug-in manages disconnection / reconnections I do not know how safe it is to change the shared / per user config live. To rule out any problems I would recommend restarting the vCO service.
using 'Share a unique session' and restarting the service did it. I flipped back to 'Session per user' and restarted the service and it was broken again so that was the trick. Is this a known bug?
Thanks,
Deric
It seems to be very likely a bug. The first step was to troubleshoot and give you a work around. Now since there is value in using the per session mode there should definitely be a bug opened for this. The best way to achieve this is that as a VMware customer you open a support request. This will insure this is kept at higher priority and can be part of a next release.
Sorry for the inconvenience.
Christophe.