API : Able to change VM settings while in Running state

[Max D]

Using Web Services & Java
Virtualbox version : 4.2.18 official release
API Version : 4.2.18 official package

Java version

noteirak@HB-Wheezy-4-2-18:/data$ java -version
java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1~deb7u1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

Linux version

noteirak@HB-Wheezy-4-2-18:/data$ uname -a
Linux HB-Wheezy-4-2-18 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux
noteirak@HB-Wheezy-4-2-18:/data$ cat /etc/debian_version
7.1

Given the following bit of code

import org.virtualbox_4_2.IMachine;
import org.virtualbox_4_2.IProgress;
import org.virtualbox_4_2.ISession;
import org.virtualbox_4_2.IVirtualBox;
import org.virtualbox_4_2.LockType;
import org.virtualbox_4_2.VirtualBoxManager;

public class VBDebug {
   
   public static void main(String[] args) {
      System.out.println("Starting");
      VirtualBoxManager vboxManager = VirtualBoxManager.createInstance(null);
      vboxManager.connect("http://localhost:18083", "", "");
      IVirtualBox vbox = vboxManager.getVBox();
      
      IMachine machine = vbox.createMachine(null, Long.toString(System.currentTimeMillis()), null, "Other", null);
      System.out.println("VM UUID: " + machine.getId() + " | Name: " + machine.getName());
      machine.setMemorySize(128l);
      machine.saveSettings();
      vbox.registerMachine(machine);
      
      System.out.println("Starting VM");
      ISession session = vboxManager.getSessionObject();
      IProgress p = machine.launchVMProcess(session, "headless", null);
      p.waitForCompletion(-1);
      session.unlockMachine();
      
      System.out.println("VM state: "+machine.getState().toString());
      System.out.println("Memory Amount: " + machine.getMemorySize());
      
      System.out.println("Modifying VM settings");
      machine.lockMachine(session, LockType.Shared);
      session.getMachine().setMemorySize(256l);
      session.getMachine().saveSettings();
      session.unlockMachine();
      
      System.out.println("VM state: " + machine.getState().toString());
      System.out.println("Memory Amount: " + machine.getMemorySize());
      
      System.out.println("Stopping VM");
      machine.lockMachine(session, LockType.Shared);
      p = session.getConsole().powerDown();
      p.waitForCompletion(-1);
      session.unlockMachine();
      
      System.out.println("VM state: " + machine.getState().toString());
      System.out.println("Memory Amount: " + machine.getMemorySize());
      
      vboxManager.disconnect();
      vboxManager.cleanup();
      System.out.println("Closing");
   }
   
}

I am able to modify the VM settings while the VM is in a RUNNING state.
This is not possible with all the front-ends provided by Virtualbox, and from my understand should not be possible in the first place.

Output of the following code :

Starting
VM UUID: 842d4418-c686-44bf-9a71-6737d8f34e87 | Name: 1381166282364
Starting VM
VM state: Running
Memory Amount: 128
Modifying VM settings
VM state: Running
Memory Amount: 256
Stopping VM
VM state: PoweredOff
Memory Amount: 256
Closing

And some vboxmanage commands

noteirak@HB-Wheezy-4-2-18:/data$ vboxmanage showvminfo 1381166282364 | grep -i "memory size"
Memory size:     256MB
noteirak@HB-Wheezy-4-2-18:/data$ grep "Memory RAMSize" ~/VirtualBox\ VMs/1381166282364/1381166282364.vbox
      <Memory RAMSize="256" PageFusion="false"/>

[Klaus Espenlaub]

Scratching my head. There is no difference between Java and other API clients if they call the same methods. In the Java case it ends up either in JAX-WS (webservice case, which talks to a webservice) which simply invokes the local API just like VBoxManage would), Jacob (COM case, which ends up in some JNI DLL), or jxpcom (XPCOM case, which ends up in some JNI .so/.dylib file), each of them implemented in C++ and calling exactly the same API methods as VBoxManage would.

It must be a bug in the "mutable" check, because it should trigger, set the error message and bail out, preventing the new value from being remembered. I have this eerie feeling that it's something special about the session object returned by launchVMProcess, which your code is reusing. VBoxManage doesn't do that.

[Max D]

I'm afraid I'll have to disappoint you - I can reproduce the same behavior using a new session object.
I can even reproduce it by doing a clean disconnect after starting the VM, exiting the JVM, start it again and directly editing the VM settings.
All this in 4.3.12 in Webservice AND in XPCOM.

[Klaus Espenlaub]

My feeling apparently wasn't right. The "mutable" check is simply broken (and has been like this for years it seems). Quite a mystery why it generally works reasonably well with VBoxManage, but again this might be a misperception, because usually no one even tries to make such changes while the VM is running.

[Klaus Espenlaub]

An at most extremely indirectly related bug reminded me of this. Made an attempt at fixing this in the next major release (trunk). Don't dare to touch 4.3 or older as it might break API clients (wouldn't rule out that our own code is free of incorrect assumptions - impossible to know as the buggy code silently would've worked just fine). It could be considered an API change which our policy forbids once the major release is out.

Oh, and the reason why VBoxManage modifyvm "does the right thing" is simply because it uses LockType_Write, i.e. it requests an exclusive session lock which rules out concurrent activities including running VMs. Only viable because we cleanly separate between modifyvm (exclusive) and controlvm (shared). I expect most 3rd party code out there to use more or less only the shared lock variant, because it's the "lazy option".

[Klaus Espenlaub]

This was fixed with 5.0, about 1.5 years ago. Closing.