It seems that also another command is affected:

2014-07-01 17:52:10,080 INFO  [org.ovirt.engine.core.bll.RemoveSnapshotSingleDiskLiveCommand] (DefaultQuartzScheduler_Worker-59) [191ea7e5] Executing Live Merge command step MERGE
2014-07-01 17:52:10,101 ERROR [org.ovirt.engine.core.bll.CommandsFactory] (DefaultQuartzScheduler_Worker-59) [191ea7e5] Cant find constructor for type org.ovirt.engine.core.bll.MergeCommand with parameter types: [class org.ovirt.engine.core.common.action.MergeParameters]
2014-07-01 17:52:10,102 ERROR [org.ovirt.engine.core.bll.CommandsFactory] (DefaultQuartzScheduler_Worker-59) [191ea7e5] An exception has occured while trying to create a command object for command Merge: java.lang.RuntimeException: could not find matching constructor for Command class class org.ovirt.engine.core.bll.MergeCommand
        at org.ovirt.engine.core.bll.CommandsFactory.findCommandConstructor(CommandsFactory.java:197) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandsFactory.createCommand(CommandsFactory.java:61) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandsFactory.createCommand(CommandsFactory.java:53) [bll.jar:]
        at org.ovirt.engine.core.bll.tasks.CommandExecutor.executeAsyncCommand(CommandExecutor.java:109) [bll.jar:]
        at org.ovirt.engine.core.bll.tasks.CommandCoordinatorImpl.executeAsyncCommand(CommandCoordinatorImpl.java:76) [bll.jar:]
        at org.ovirt.engine.core.bll.tasks.TaskManagerUtil.executeAsyncCommand(TaskManagerUtil.java:167) [bll.jar:]
        at org.ovirt.engine.core.bll.RemoveSnapshotSingleDiskLiveCommand.proceedCommandExecution(RemoveSnapshotSingleDiskLiveCommand.java:145) [bll.jar:]
        at org.ovirt.engine.core.bll.RemoveSnapshotSingleDiskLiveCommandCallback.doPolling(RemoveSnapshotSingleDiskLiveCommandCallback.java:18) [bll.jar:]
        at org.ovirt.engine.core.bll.tasks.CommandExecutor.invokeCallbackMethods(CommandExecutor.java:75) [bll.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
        at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
        at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:60) [scheduler.jar:]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:]
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557) [quartz.jar:]

Ravi, can you take a look?  Seems that CommandExecutor isn't looking for constructors with the CommandContext parameters, which affects all the internal Live Merge commands.

Can be resolved by adding constructors with out CommandContext

public RemoveSnapshotSingleDiskLiveCommand(T parameters) {
..
}

(In reply to Ravi Nori from comment #3)
> Can be resolved by adding constructors with out CommandContext
> 
> public RemoveSnapshotSingleDiskLiveCommand(T parameters) {
> ..
> }

Thanks Ravi.  I was under the impression that internal commands, such as those affected here, only needed a single constructor accepting parameters and the context ([1], section 3).  If that's not true for CommandExecutor-style commands I think that's fine, we just need to be sure to establish a convention.  We also will want to ensure we don't need to support any of the context modifications ([1], section 1).

[1] http://lists.ovirt.org/pipermail/devel/2014-June/007869.html

CommandCoordinator has to be modified to persist and use command context to look up constructors, but command context is not serializable. I am working on it.

(In reply to Greg Padgett from comment #4)
> (In reply to Ravi Nori from comment #3)
> > Can be resolved by adding constructors with out CommandContext
> > 
> > public RemoveSnapshotSingleDiskLiveCommand(T parameters) {
> > ..
> > }
> 
> Thanks Ravi.  I was under the impression that internal commands, such as
> those affected here, only needed a single constructor accepting parameters
> and the context ([1], section 3).  If that's not true for
> CommandExecutor-style commands I think that's fine, we just need to be sure
> to establish a convention.  We also will want to ensure we don't need to
> support any of the context modifications ([1], section 1).
> 
> [1] http://lists.ovirt.org/pipermail/devel/2014-June/007869.html

That depends how you're invoking the command.

What I meant in my last comment -
Currently we cannot limit invoking internal commands to only the case where context is passed. Therefore, there might be cases where you will need a ctor without context.

oVirt 3.5 has been released and should include the fix for this issue.