Workflow failing all of a sudden

[goody3335]

I created a workflow that was working fine a few weeks ago.  I used the scheduler to make it reoccur every Friday.  It was fine for a bit, but now it fails, even when I try to run it manually.  I don't get any errors in the client other than it just saying error and workflow has failed.  Even under the logs tab...it's just blank.  I thought I remembered it showing me what it was doing before.

I haven't applied any upgrades.  I was thinking maybe it was of a password change or something, but I have it configured to use a service account and the password hasn't changed recently.  It seems to fail pretty much right away.

This is vCO 4.1.1. 

Any suggestions?

[goody3335]

I should also mention that I've tried validating the workflow and that completes successfully.

[Burke-]

We would need more detail on the issue and the workflow - screenshots, log files, etc...

Without any of those, the first things that come to my mind are:

1. Did the account that is used by vCO to access vCenter get its password changed?
2. Is this a cloning/snapshot operation - if so, have you run out of drive space?

[tschoergez]

Hi!

I think you have to share your workflow, or at least some more description about the different elements.

Can you reproduce, at which element the error occurs?

Can you create a backup-copy of the workflow, and add some "tracer ammunition" System.debug or System.log entries?

Can you find something in server.log or scripts-log.log?

(file location: see http://www.vcoportal.de/troubleshooting/ :smileycool: )

Regards,

Joerg

[goody3335]

Yeah, I knew I was lacking a lot of info...but I wasn't sure where to start.  So here's some more info based on your posts:

It doesn't show me which element it fails at.  I just try to start the workflow and it fails pretty immediately.

Here's something interesting...I tried one of the pre-existing workflows (disconnect attached devices) and that also fails immediately without telling me why.  I am logged in to vCenter Orchestrator with the same credentials I have been using from the beginning, though.

I'm using the local system account for the vco services.  When I go into the vCO confgiration and test LDAP, it works fine.  It tells me the user I've tested with is a member of the vCO administration group...which is also the user I log in to vCO client with.  I'm using a local admin user account and password to login to vCenter and that password has not changed.  Also, I'm able to pull up the inventory and all that, which I would think wouldn't work if I couldn't login to vCenter from vCO.

Here is a snippet from the log file:

Added property's filters '[parent, name, snapshot, summary]' for managed object reference(s) '[vm-53011, vm-55131]'

2011-04-27 14:35:48.117-0400 INFO  [FiltersManager] createPropertyFilter() [administrator@http://192.168.100.79:80/sdk/Main#730811b5, Nb filters used 83] --> Added property's filters '[parent, name, snapshot, summary]' for managed object reference(s) '[vm-54712, vm-53743]'

2011-04-27 14:35:56.288-0400 INFO  [Execution] Executing workflow 'Disconnect all detachable devices from a running virtual machine'

2011-04-27 14:35:56.489-0400 WARN  [WorkflowHandler] Error in execution of workflow 'Disconnect all detachable devices from a running virtual machine'

java.lang.NoClassDefFoundError: Could not initialize class com.vmware.vmo.plugin.vix.VixServer

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Class.java:247)

at ch.dunes.vso.sdk.SDKModuleDescription.defineInScope(SDKModuleDescription.java:453)

at ch.dunes.vso.sdk.ModulesFactory.defineInScope(ModulesFactory.java:412)

at ch.dunes.scripting.jsmodel.Definitions.doDefineModelInScope(Definitions.java:94)

at ch.dunes.scripting.jsmodel.Definitions.defineModelInScope(Definitions.java:48)

at ch.dunes.scripting.server.script.MainScriptingObject.<init>(MainScriptingObject.java:144)

at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.execute(WorkflowHandler.java:183)

at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.run(WorkflowHandler.java:155)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

at java.util.concurrent.FutureTask.run(FutureTask.java:138)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:619)

2011-04-27 14:35:56.509-0400 WARN  [WorkflowHandler] Unable to Clean Scripting context

java.lang.NullPointerException

at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.end(WorkflowHandler.java:527)

at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.execute(WorkflowHandler.java:257)

at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.run(WorkflowHandler.java:155)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

at java.util.concurrent.FutureTask.run(FutureTask.java:138)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:619)

I see that there is an error: Could not initialize class com.vmware.vmo.plugin.vix.VixServer

I'm not exactly sure what to do with that, though...or why anything would be different than it was a few weeks ago.

Thanks!

[Burke- · Accepted solution]

Have you been using the VIX plug-in or did you just install it?

If you just installed it, then this msg indicates that you did not copy the VIX libraries (unzip the archive distributed with the plugin as described in the docs) to your system and add the path to the environment path. If you either add the path to the VIX libraries, or remove the VIX plugin, your workflows should resume working

[goody3335]

Thanks for your help!  It's weird that the VIX plugin was the issue because I've had that on there since before I created any workflows.  Perhaps I had a server restart or something that enabled it, though.

Thanks again!

***For those reading this that don't know how to uninstall the plugin...go into the vCO configuration, under the plugins tab and uncheck that.  You'll probably need to restart the service or the server under the Startup tab as well.  I had to do it a couple different times before it was actually gone out of my inventory on the vCO client.

[tschoergez]

Great, when it works now 🙂

Side note to VMware's plugin development team:

Consider some chekup-routines for plugin setup, to prove that all external components (like the VIX-dlls here) are installed properly before the plugin is activated....

Regards,

Joerg

[VirtualVargi]

Thanks for the solution saved me lots of time.