Wrong locking mode for VM setting edit makes VM permanently stuck

[Max D]

Using the Webservice Java API, if LockType.Shared is used on modifying a powered off VM setting, this will cause the VBOX_E_INVALID_OBJECT_STATE (0x80bb0007) error to occur on any following call to control the VM (start, stop). The setting will be modified successfully.

The only authorised action will be to modify settings with a LockType.Shared.

Subsequent call to modify settings with LockType.Write will cause the error aswell.

The only way to get the VM back to usable is to shutdown all the VMs on the host, wait for VboxXPCOM & VboxSDL to shutdown. After that, all is back to normal.

The following code is used to cause the bug :

public void set(VirtualboxMachine vm, _Setting setting) {
		IMachine machine = ConnectionManagerFactory.get().getBox().findMachine(vm.getUuid());
		ISession session = ConnectionManagerFactory.get().getSession();
		machine.lockMachine(session, LockType.Shared);

		if (actions.containsKey(setting.getName())) {
			actions.get(setting.getName()).set(session.getMachine(), setting);
		} else {
			defaultAction.set(vm, setting);
		}

		session.getMachine().saveSettings();
		session.unlockMachine();
	}

behaviour after this call :

virtualbox@gateway:~$ vboxmanage showvminfo TestVM | grep -i state
State:           powered off (since 2012-11-22T22:51:25.475000000)
virtualbox@gateway:~$ vboxmanage startvm TestVM --type headless
VBoxManage: error: The machine 'TestVM' is already locked by a session (or being locked or unlocked)
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component Machine, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LaunchVMProcess(a->session, sessionType.raw(), env.raw(), progress.asOutParam())" at line 580 of file VBoxManageMisc.cpp
virtualbox@gateway:~$

The expected behaviour would be for the lock to be released or for the saveSettings() to fail since LockType.Write is expected

[Max D]

Replying to noteirak:

The only way to get the VM back to usable is to shutdown all the VMs on the host, wait for VboxXPCOM & VboxSDL to shutdown. After that, all is back to normal.

Apparently, the vboxwebsrv must be shutdown aswell, or the lock is not release - possibly the element that actually holds the lock without releasing it?

Also please note that the VM state changed to aborted when the vboxwebsrv finishes.

[mike123]

I happen to see this as well when I try to force power off or use the ACPI power off method through webservices. When my machine state becomes the state prior to aborted, I have to restart the webservices in order for the machine state to actually become aborted.

I have also seen this issues while running Virtualbox 4.2.8

Is there a time frame that this will be fixed?

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.