java.lang.NoClassDefFoundError issue when running workflow

Good afternoon,

The following issue was observed when working with the same workflow on vRO 7.3, 7.4 and 7.5 (including a fresh vRO deploy).

I'm building a linked clone workflow from scratch so as to get a better understanding of how the API works.

I'm facing an execution error on the "Define linked clone" scriptable task element below (although picture shows green, it's an exception).


What's in the scriptable task:


var cloneSpec = new VcVirtualMachineCloneSpec;

cloneSpec.config = configSpec;

if (customize)


cloneSpec.customization = guestSpec;


cloneSpec.location = new VcVirtualMachineRelocateSpec;

cloneSpec.location.datastore = datastore;

cloneSpec.location.pool = pool;

cloneSpec.location.diskMoveType = "createNewChildDiskBacking";

cloneSpec.snapshot = vmSnap;

cloneSpec.powerOn = false;

System.log("All set");


Scriptable task INPUTs:

datastore (VC:Datastore)

configSpec (Any - VCVirtualMachineConfigSpec)

guestSpec (Any - VCCustomizationSpec)

vmSnap (VC:VirtualMachineSnapshot)

customize (Boolean)

pool (VC:ResourcePool)

Scriptable task OUTPUTs:

cloneSpec (Any - VCVirtualMachineCloneSpec)


The issue:

When running the workflow (does not matter if customizing guest os or not) the workflow finish with an exception:


What I find strange is that the scriptable task finishes (since I can see the "All set" message) and the next element (the clone VM action) does not run. To me it looks like that the exception is happening at the blue line between the two elements. By checking the server.log file I found this particular sequence:

"java.lang.NoClassDefFoundError: com/vmware/o11n/service/profiler/IProfiler$$Lambda$51/1242788072" (followed by a huge java dump)

And then the workflow exception:

2018-11-12 14:32:01.077-0200 [WorkflowExecutorPool-Thread-1] ERROR {|__SYSTEM|<user>:Criar linked clone:bb8fbd4e-8efa-47c2-bf90-ddbaa9baf872:token=ba330cb2-7efb-48cb-8eb8-94c953c18f5d} [SCRIPTING_LOG] Workflow execution stack:


', state: 'failed', business state: 'null', exception: 'null'

*** End of execution stack.

Another strange thing is if I try to run this workflow a second time (without wating something like 30-60 seconds) the vco-server service crashes and stops running (with no output inside server.log).

I remember facing a similar issue in the past which was "solved" by not outputing the cloneSpec and calling the cloneVM_Task method inside the same Scriptable Task but now I'm trying to solve it and not working around it.

I already tried creating a file called "/custom/classes.conf", populating it with "java.*" (without quotes) and then creating the "com.vmware.scripting.rhino-class-shutter-file" system property but that didn't work (I'm also a complete java noob so I have no idea if what I was doing was actually correct).

I thank you very much everyone for your time and any possible advice on the matter.

0 Kudos
6 Replies
VMware Employee
VMware Employee


Profiler code is a relatively new addition to vRO code base, so there could be some issues / bugs.

It will be very helpful if you can attach a sample complete workflow that we can use in our environment to reproduce the problem, plus the content of the log file to check the Java stack trace. Or, if you prefer, you can open an official support request.

0 Kudos

Hello, Ilian, and thanks for the reply.

Attached workflow and its server.log execution.

0 Kudos
VMware Employee
VMware Employee

Thanks for the workflow. I was able to reproduce a similar error using it in my local 7.6 environment. Reminds me of object deserialization issues we had with the vCenter plug-in in 7.3 maybe an year ago.

I'll open an internal PR to check this issue further, but if you need an urgent fix, you can open an official support request (these requests are prioritized higher than internal PRs).

0 Kudos
VMware Employee
VMware Employee

The workaround you mentioned is the legitimate solution for this issue. Orchestrator persists workflow run state when transition from one workflow item to other to be able to resume the workflow in case of crash. To be able to do this in/out/attribute variables should be serializable. So called 'findable' objects (mostly those visible in plugin's inventory) are serialized in form of URI consisting of (object type; object id). There is no such mechanism for plugin objects that do not have id like VcVirtualMachineCloneSpec - it is pure java POJO.

0 Kudos

I see.

I can live with the workaround but it does not explain why I don't see similar errors with the other objects, like the customizationspec, the virtual disk and the vmxnet3 adapter, since they also don't have ids (at least I can't see it in the API Explorer).

Also, Orchestrator has a default action called getCloneSpec that outputs a VcVirtualMachineCloneSpec as "Any", the same way I do at the workflow.

Well, like I said, I can live with the workaround or use the default action, but that still leaves with me that little "why" in the back of my head.

0 Kudos

Here's an interesting update.

If I remove the .snapshot attribute from the VcVirtualMachineCloneSpec object, the exception does not happen.

If you add it, it happens.

I noticed because I replaced my scriptable task with the getCloneSpec default Orchestrator action and although the linked clones was not created (because the default action does not have the snapshot attribute) the workflow finished "successfully".

I copied the action and created a new one, adding the snapshot attribute and BANG: there's the issue again.

0 Kudos