VirtualBox

Ticket #12164 (new defect)

Opened 17 months ago

Last modified 8 months ago

API : Able to change VM settings while in Running state

Reported by: noteirak Owned by:
Priority: major Component: VM control
Version: VirtualBox 4.2.18 Keywords:
Cc: Guest type: all
Host type: Linux

Description

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"/>

Change History

comment:1 Changed 9 months ago by klaus

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.

comment:2 Changed 9 months ago by noteirak

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.

comment:3 Changed 8 months ago by klaus

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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use