virtualbox.org

We have encountered an issue with Java API for VirtualBox.

When Tomcat opens the VirtualBox API, the VBoxSVC process will start if it is not already running. If it starts from Java, it will bind to the ports that the Java process has bound, including the HTTPS port.

Since VBoxSVC will keep running until all processes that use it are shut down, this can prevent the Tomcat application from restarting again. When this occurs, we have to shut down all VMs, which is undesirable.

ENVIRONMENT INFORMATION:

OS: Solaris (5.11, oi_151a2)
VirtualBox: 4.1.12r77245
Java: 1.6.0_26

STEPS TO REPRODUCE:

Ensure that VBoxSVC is not running: ps -ef | grep VBox

Compile the test code (see below): pfexec javac -cp PATH/TO/vboxxpcom.jar VboxDemo.java
pfexec javac -cp /opt/VirtualBox/sdk/bindings/xpcom/java/vboxjxpcom.jar VboxDemo.java

Start the program with: pfexec java -cp .:PATH/TO/vboxjxpcom.jar -Dvbox.home==VIRTUALBOX_HOME_DIR -Djava.library.path=PATH_TO_VIRTUALBOX_LIBRARY VboxDemo

Example: pfexec java -cp .:/opt/VirtualBox/sdk/bindings/xpcom/java/vboxjxpcom.jar -Dvbox.home==/opt/VirtualBox -Djava.library.path=/opt/VirtualBox/i386 VboxDemo

This code will bind to port 4444, initialize the VirtualBox API, and then wait for input before terminating.

From a different terminal, confirm that VBoxSVC is running, and retrieve the process ID:
$ ps -ef | grep VBoxSVC
root 14965 1 0 16:14:32 ? 0:00 /opt/VirtualBox/amd64/VBoxSVC --auto-shutdown

Run this command, and note that binds to port 4444: pfexec pfiles <pid>

Code: Select all

import java.io.IOException;
import java.net.ServerSocket;

import org.virtualbox_4_1.IVirtualBox;
import org.virtualbox_4_1.VirtualBoxManager;

public class VboxDemo {

	public static void main(String args[]) throws IOException {

		System.out.println("Please stop VBoxSVC process before running the test,");
		System.out.println("command to do test:");
		System.out.println("java -cp DIROFCLASSFILE:PATHTO_vboxjxpcom.jar -Dvbox.home=ROOT_OF_VBOX -Djava.library.path=ROOT_OF_VBOX/i386 VboxDemo");
		try {
			// open port 4444
			ServerSocket ss = new ServerSocket(4444);
			// start one process from java (to compare to VBoxSVC)
			Runtime.getRuntime().exec(
					new String[] { "/usr/gnu/bin/sleep", "600" });

			// ss.close();
		} catch (IOException e) {
			e.printStackTrace();

		}
		// use Vbox api, VBoxSVC process will be started by the api
		VirtualBoxManager mgr = VirtualBoxManager.createInstance(null);
		IVirtualBox vbox = mgr.getVBox();
		vbox.getMachines();

		// Now VBoxSVC should be started and binded to port 4444
		// but the sleep process is not binded to port 4444
		System.in.read();

	}

}

Thank you,
Dinu Zabrauteanu

Seems like a Java/tomcat specific issue rather than a virtualbox. To me, it is as if Tomcat doesn't clean its child processes correctly.
AFAIK Tomcat keeps some code running in memory, and I doubt Virtualbox is made to deal with it, so it wouldn't be supported anyway. On the of the devs could maybe confirm?

It isn't tomcat's issue : the demo application doesn't use tomcat at all.
It isn't java's issue as well. The demo code creates one "sleep" process. If it is bug of java, the sleep process should also listen on port 4444 but it's not.

Therefore, something happens and VBoxSVC binds on the 4444 port for unkown reason.

I really need to understand why this is happening. I'm sure you can replicate the issue quite easy.

Thank you,
Dinu

When Tomcat opens the VirtualBox API, the VBoxSVC process will start if it is not already running. If it starts from Java, it will bind to the ports that the Java process has bound, including the HTTPS port.
Since VBoxSVC will keep running until all processes that use it are shut down, this can prevent the Tomcat application from restarting again. When this occurs, we have to shut down all VMs, which is undesirable.

Well you do talk about Tomcat using the Virtualbox API, and then talk about the HTTPS port, which is 443, and would be used by Tomcat, so I am a t lost here. Why do you mention Tomcat in the first place?

I will try your code tonight, but I have my own code doing some socket work aswell, and I never saw this kind of behaviour. We'll see.

A bit late answer, I did not have much time to try this out yet, but I noticed few things reading your post again, so I have two questions for you :
- Do you use the Java XPCOM connector for this?
- Have you tried with the 4.2.x version of Virtualbox?

Hello,

To answer your questions:

Q:- Do you use the Java XPCOM connector for this?
A: Yes, we are using Java XPCOM

Q:- Have you tried with the 4.2.x version of Virtualbox?
A: We have only tested this with VirtualBox 4.1.12. I will plan to run a test with 4.2.x today.

Thank you,
Dinu Zabrauteanu

Ok then I cannot even try to reproduce it : This bug prevents it on Linux. But I am very much interested in the 4.2 try

virtualbox.org

VirtualBox port binding issue

VirtualBox port binding issue

Re: VirtualBox port binding issue

Re: VirtualBox port binding issue

Re: VirtualBox port binding issue

Re: VirtualBox port binding issue

Re: VirtualBox port binding issue

Re: VirtualBox port binding issue