VirtualBox starts on an incorrect X-Server -> fixed in SVN/1.5.0

[Technologov]

Platform: openSUSE Linux 10.2, VBox 1.3.8

When I have two X-servers running, VirtualBox Manager starts where I ask it to start, but the VMs are always started on the first X server (that is: display :0), even if they are launched from second X-server by VirtualBox Manager.

to reproduce:

1. KDE Start Menu->Start New Session (or startx -- :1) to start a 2nd X-Server

2. Try running some VBox VMs on the 2nd X-Server.

[Technologov]

Bug verified with VBox 1.4.0 on openSUSE Linux 10.3 alpha4.

That is: VBox should use the Linux standard: $DISPLAY parameter to see on which X-Server it must start.

This bug basically prevents execution of VBox on remote Linux machines via X or NX protocols.

-Alexey "Technologov"

[xeyes]

I confirm this bug too.

The slight difference is that i run only ONE xserver serving two SCREENs. $DISPLAY is ignored too. VM is started on the wrong SCREEN. xorg v7.2.0 on gentoo linux 2.6.21 + gentoo-patches + suspend2 patch

Example: VM-Manager runs p.e. on :0.1 VM is started on :0.0

[xeyes]

Replying to xeyes:

I confirm this bug too.

The slight difference is that i run only ONE xserver serving two SCREENs. $DISPLAY is ignored too. VM is started on the wrong SCREEN. xorg v7.2.0 on gentoo linux 2.6.21 + gentoo-patches + suspend2 patch

Example: VM-Manager runs p.e. on :0.1 VM is started on :0.0

Sorry, forgot to tell that i'm using VBox 1.4.0

[nbecker]

Any progress on this, or workaround?

[Frank Mehnert]

Actually the VM is started at the X server the VBoxSVC server was started from. Try the following:

• make sure that no instance of VBoxSVC is running
• start the VBoxSVC server manually from the X server you want the VM running on

  LD_LIBRARY_PATH=/opt/VirtualBox-1.4.0 VBoxSVC
  

• start the VirtualBox GUI and launch a VM

At least this works here on Debian/sid with Xorg 7.2.

[Technologov]

Well I don't know what it is, but VBoxSVC looks like a components that talks between VirtualBox and vboxdrv. Is this correct ? Why is it needed at all ?

But you are correct, yes, after manually starting VBoxSVC on a different X terminal, the VMs appeared there. But it's just a workaround, not a fix.

My system: openSUSE 10.2.

The correct behavior would be to start VMs on the same X terminal, from which the GUI "launched" them. If VBoxSVC is a daemon, it should be accessible from everywhere...

Maybe a GUI should pass it a $DISPLAY parameter, when it launches a VM ?

[Frank Mehnert]

I'm fully aware that this is only a workaround and we will fix this soon or later. The VBoxSVC server is needed for synchronized access to ressources and the VM states. For instance, you can start several concurrent instances of the VirtualBox GUI all showing the same correct state of your VMs.

[Frank Mehnert]

Fixed in svn. Fix will be included in VirtualBox 1.5.0.