VirtualBox

Ticket #261 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

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

Reported by: Technologov Owned by:
Priority: major Component: other
Version: VirtualBox 1.3.8 Keywords:
Cc: Guest type: other
Host type: other

Description

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
  1. Try running some VBox VMs on the 2nd X-Server.

Change History

comment:1 Changed 7 years ago by 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"

comment:2 follow-up: ↓ 3 Changed 7 years ago by 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

comment:3 in reply to: ↑ 2 Changed 7 years ago by 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

comment:4 Changed 7 years ago by nbecker

Any progress on this, or workaround?

comment:5 Changed 7 years ago by frank

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.

comment:6 Changed 7 years ago by 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 ?

comment:7 Changed 7 years ago by frank

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.

comment:8 Changed 7 years ago by frank

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

comment:9 Changed 7 years ago by sandervl73

  • Summary changed from VirtualBox starts on an incorrect X-Server to VirtualBox starts on an incorrect X-Server -> fixed in SVN/1.5.0

comment:10 Changed 7 years ago by sandervl73

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use