VirtualBox

Opened 13 years ago

Closed 8 years ago

#8175 closed defect (obsolete)

GUI is very slow when running it via an ssh tunnel (was kind of fast for 3.2.12)

Reported by: Uli Heller Owned by:
Component: GUI Version: VirtualBox 4.0.2
Keywords: Cc:
Guest type: other Host type: Linux

Description (last modified by Frank Mehnert)

Hi,

I used to administer a VirtualBox host via a remote ui (VirtualBox) tunneled through a slow ssh tunnel (it is a WAN connection basically). For 3.2.12, this worked reasonably well. For 4.0.2, it doesn't work at all. You'll have to wait minutes, before the UI appears on the screen. Afterwards, it is not responsive at all. All of this is based on Ubuntu-10.04 of course.

At first, I thought the screen preview feature of the new ui causes these issues. So I disabled it using

$ VBoxManage setextradata global "GUI/DetailsPageBoxes" "general,system,display,storage,audio,network,usb,sharedFolders"

Unfortunately, no improvement. I'm going to measure the amount of data transfered over the ssh tunnel next and I'll attach my findings to the ticket.

Best regards + many thanks, Uli

Change History (50)

comment:1 by Uli Heller, 13 years ago

We (a collegue of mine and myself) did a few tests. For 3.2.12, less than 1 MB is transferred when starting the GUI. For 4.0.2, roughly 4 MB is transferred. I guess this explains why it feels so slow...

comment:2 by Uli Heller, 13 years ago

Now we got even more data:

  • 3.2.12: Roughly 1 MB of data transferred on startup of the UI
  • 4.0.2 with preview: Roughly 4 MB of data
  • 4.0.2 without preview: Roughly 3 MB of data

comment:3 by Drazen Tomic, 13 years ago

I have exactly the same issue.

We are not talking here in some seconds more, but minutes (!!!) to wait after each click.

I have one machine, openSUSE 11.2, Linux xxxxxx 2.6.31.14-0.4-desktop #1 SMP PREEMPT 2010-10-25 08:45:30 +0200 i686 athlon i386 GNU/Linux with KDE 4 and VirtualBox 4.0.2_OSE r35621 -> running perfectly over ssh -X

Another machine, also openSUSE 11.2, Linux xxxxxx 2.6.31.14-0.6-default #1 SMP 2010-12-10 11:18:32 +0100 x86_64 x86_64 x86_64 GNU/Linux with the same VirtualBox -> damned / extremely /very slow

I tried:

  • all versions of 4.x (from openSUSE standard repo and from Oracle repo)
  • changing to the same kernel-desktop
  • installing KDE (yes, I was a little desperate)
  • access the server from different networks and machines

I looked:

  • in every possible log file
  • ran ssh with the -vvv option

Nothing helped.

The only solution was to install 3.2. 3.2 runs perfectly well over ssh -X

Maybe:

  • the 64-bit version ?
  • Server runs at Hetzner ? (was perfect until now)

Best regards Tom

comment:4 by Technologov, 13 years ago

Added myself as CC to this issue.

-Technologov

comment:5 by Frank Mehnert, 13 years ago

Let me understand your issue: Do you also start your VMs through the GUI (and therefore the VMs appear on the remote host) or do you only start the GUI for changing VM settings or for monitoring running VMs?

comment:6 by Uli Heller, 13 years ago

I'm only trying to verify and change the vm settings. For example I'm trying to change the amount of video ram.

I do access the consoles of the VMs via "rdesktop" as well. I'm using an SSH tunnel for this, too. It works as usual meaning it is reasonably fast with 3.2 and 4.0.

So to summarize: The VM configuration/verification screen with the window title "Oracle VM VirtualBox Manager" is slow for 4.0.2, even when the preview window is deactivated.

Best regards and thanks a lot for your support, Uli.

comment:7 by Drazen Tomic, 13 years ago

I start also *only* the GUI for settings - no virtual machines started

PS: As we are setting the servers up, I could give a root password to someone how is from the VirtualBox Project

comment:8 by Guido Ostkamp, 13 years ago

Hello,

I have the same problems as descibed in the report.

I am running Vbox 4.0.2 on a remote display (via "export DISPLAY=..."). The Display is a PC using Nomachines nxclient which connects to a Solaris box. From there the 'slogin -X' session is made to the Vbox host which is a RHEL 6 machine.

It turned out that with Vbox 4.0.2 all GUI operations are awfully slow, the GUI is nearly unusable. One has to wait several seconds up to half a minute until simple GUI elements become visible, e.g. windows open up or selection box changes get visible. This was not seen with the latest Vbox 3 versions where the GUI was quite responsive.

comment:9 by gnanasekar velu, 13 years ago

Hi I am also facing the same problem and gui is very slow is there any solution?

comment:10 by diver, 13 years ago

Same thing here. 4.0.2 gui is very slow on ubuntu 10.10.

comment:11 by Drazen Tomic, 13 years ago

Hi,
Is there any solution?
Is there an improvement in 4.0.4 ?
Thank you

comment:12 by Technologov, 13 years ago

Not listed in changelog, so not fixed.

-Technologov

comment:13 by wlet, 13 years ago

Same problem here. Checked the avail. Bandwidth and it is >80MBit/s in both directions.

comment:14 by Ari, 13 years ago

Same issue with 4.0.4, on a headless production server running ubuntu 10.04 64 bits.

This is complicating the server administration quite a bit. We upgraded virtualbox from 3.2.8

Is there any (temporary) workaround?

comment:15 by Frank Mehnert, 13 years ago

Which VirtualBox packages are you guys using? The .run package or the distribution-specific packages? Trying to reproduce this issue here I'm not successful ...

comment:16 by Drazen Tomic, 13 years ago

openSUSE 11.2, Linux 2.6.31.14-0.6-default #1 SMP 2010-12-10 11:18:32 +0100 x86_64 x86_64 x86_64 GNU/Linux
VirtualBox 4.0.2_OSE r35621

Didn't try since then. Please see third entry (2011-01-24 16:15:01)
It seems not to be related to the OSE or not version. I tried from Oracle repo and from Suse repo. Same result.

Let me see my notes:
http://download.opensuse.org/repositories/Virtualization/openSUSE_11.3 -> virtualbox 4.xxx -> extreme slow
http://download.virtualbox.org/virtualbox/4.0.2/VirtualBox-4.0-4.0.2_69518_openSUSE113-1.x86_64.rpm -> couldn't compile
http://download.virtualbox.org/virtualbox/rpm/opensuse/11.3 -> couldn't compile
http://download.opensuse.org/repositories/Virtualization/openSUSE_11.2 -> virtualbox 4.xxx -> extreme slow

Let's try to compile
4.0.2_69518_openSUSE111-1 -> loads vboxdrv but still damned slow

Hints?:
On a 32 bit machine, the speed is ok
On 3.2.12_68302_openSUSE111-1, the server crashes after some days. It starts with "ssh_exchange_identification: Connection closed by remote host" then I lost the rest (mail, apache, ping, etc)
On a Athlon the speed is ok

comment:17 by Uli Heller, 13 years ago

Hi Frank,

I'm typically using the ubuntu 64 bit packages. I download the DEB files from the virtual box web site and install them via dpkg -i ...

Shall I give a try to the generic linux packages?

Best regards, Uli

comment:18 by Frank Mehnert, 13 years ago

No, I just want to know how to reproduce these issues. What kind of Qt style are you using?

comment:19 by Uli Heller, 13 years ago

I guess you're asking about the settings in qtconfig-qt4, aren't you? For GUI style, it says "Desktop Settings (Default)". Shall I change it to a more precise setting? For example GTK+? Or are you asking for a different parameter?

comment:20 by Frank Mehnert, 13 years ago

Yes, perhaps you could try some different settings. Perhaps this depends on that style setting.

comment:21 by Uli Heller, 13 years ago

I just realized that I didn't have installed qtconfig-qt4 on the server which bothers me the most. So I installed it. Then it crashed on startup. So I had to install software-properties-gtk as well. Unfortunately, qtconfig-qt4 is awfully slow, too. It is very difficult to change the GUI style there. I changed it to GTK+.

Unfortunately, both qtconfig-qt4 and VirtualBox are still very slow. I'll try CDE and other values, but it will take time :)

So maybe this is a feature of qt4? Didn't you migrate from an older version to qt4 for VirtualBox-4.0?

comment:22 by Frank Mehnert, 13 years ago

We didn't change the Qt version with VirtualBox 4.

comment:23 by Drazen Tomic, 13 years ago

Frank,
Sorry about the question. How are you related to the VirtualBox Project?

comment:24 by Technologov, 13 years ago

Frank is one of the main VirtualBox developers, employed by Oracle.

-Technologov

comment:25 by Uli Heller, 13 years ago

3rd try: This time, I'm typing this in emacs first. Hopefully, I'm not going to lose my typings again.

So: CDE is slow, too.

My network connection has a ping time of roughly 50ms, the bandwidth is 600kB/s. With this, it takes roughly 70 seconds for the VirtualBox GUI to show up.

BTW: Thanks a lot for taking the time looking at this issue!

Best regards, Uli

comment:26 by Guido Ostkamp, 13 years ago

Hello Frank,

to answer your questions:

In office I have a Windows-PC with Nomachines nxclients. From there I log in to a Solaris 10 box with enlightenment Window manager. Then with "slogin -X" connection to a RedHat RHEL 6 64-bit system is made where I run the "VirtualBox" GUI.

I am using the RHEL 6 64-bit OS variant of Virtualbox with all extensions.

Virtualbox 3 GUI speed was ok. VirtualBox 4 GUI is awfully slow, nearly unusable. And yes, I of course did deactivate that updating of the preview pane but it doesn't help at all.

From look & feel I had got the impression that Virtualbox 3 and 4 are using completely different GUI toolkits where V3 is lightweight and V4 extremely heavy.

Of course I don't know what really happened under the hood.

Please fix this sluggish performance, it is nearly unusable in this state. I have to wait several seconds until even simple changes after button presses get visible.

comment:27 by Drazen Tomic, 13 years ago

Frank,
"Frank is one of the main VirtualBox developers, employed by Oracle. "
Cool! First, thank you *very* much for VirtualBox !!!
Second, we can provide you immediately a whole server with root access where this behavior happens. So you can reproduce and analyze the problem.

comment:28 by Technologov, 13 years ago

Bug not verified with NX.

I am successfully running VirtualBox 4.0.4 in remote mode.

Host: openSUSE 10.3 x64, VirtualBox 4.0.4 + FreeNX Server 0.7.0.

Client: Windows XP + NX Client 2.1.0.

Changing GUI settings is quick, like locally. Running VM is instant. No problems with "preview mode" either.

NOTE: The "NX" protocol is not pure "X11", as in NX many X11 commands execute at the Host, while in pure "X11" they are split between Host and the client.

-Technologov, 10.3.2011.

comment:29 by Guido Ostkamp, 13 years ago

Bug not verified with NX.

Why are you looking for NX? NX is not the problem. The 'ssh -X' connection is the problem. If you are referring to my description above, note that there is NX from Windows PC to machine 1, then ssh -X from machine1 to machine2 where Virtualbox is running.

comment:30 by Josh Litherland, 13 years ago

Raw X11 over TCP (i.e. not over SSH) is still exceptionally slow; it's better than ssh -X, but the small improvement is probably attributable to the usual SSH overhead. Running the client "locally" inside a VNC server is tens of times faster.

comment:31 by Kari, 13 years ago

I have reverse tunnel from debian lenny to freebsd 8. Connection is able to transfer about 50kB/s. It's using that speed with other programs and they are somehow usable.

Weird thing is, when i open Virtualbox 4.0.4, transfer rate is about 2 or 4kB/s and lots of patience is required. Like something is limiting it. So Virtualbox doesn't seem to be heavy, but my ssh forwarding becomes slow, when i open Virtualbox.

I used ksysguard to measure these rates. It seems to me like X or ssh issue, but that's only guessing.

comment:32 by Zarquan, 13 years ago

I have the same problem.

virtualbox

4.0.4 r70112

server

openSUSE 11.1 (x86_64)

client

Fedora 12 (x86_64)

Running VirtualBox via ssh -X is extremely slow, it takes over 2 min to display the 'About' box to check the version. Running other GUI apps via a separate ssh -X connection is fine.

The VirtualBox ssh connection seems to be limited to about 1.5kbps, but the available bandwidth is over 400kbps.

comment:33 by jlugert, 13 years ago

Same deal with a Solaris 10 10/08 server & a Mac client.

Jerry

comment:34 by Drazen Tomic, 13 years ago

@Frank

Hi Frank,
Do you need the root access to our physical machine where you can reproduce it?
We need to begin to use the server so I can't let it unproductive much more time.

Best regards

comment:35 by Drazen Tomic, 13 years ago

Same with openSUSE 11.4 and VirtualBox 4.0.6_71344_openSUSE114-1

I need to move on, so I am using TightVNC and ssh port forwarding - it's fast enough.

So we have:

comment:36 by O.J. Sousa Rodrigues, 13 years ago

same with debian lenny 64bit and mac client same with ubuntu hardy 64bit and mac client

comment:37 by Stéphane, 12 years ago

Same problem here with both a x86_64 lucid Ubuntu as client and server.

As reported, while the GUI takes minutes to appear (and trust me you'd better not click anywhere when it's open), the bandwidth used is pretty low, far less than wha's available.

Using Xtrace it appears that there are hundreds of identical QueryPointer / TranslateCoordinates sequences...

000:<:04cf:  8: Request(38): QueryPointer window=0x00000168
000:>:04cf:32: Reply to QueryPointer: same-screen=true(0x01) root=0x00000168 child=0x0226a4e1 root-x=1250 root-y=241 win-x=1250 win-y=241 mask=Control,Mod2
000:<:04d0: 16: Request(40): TranslateCoordinates src-window=0x00000168 dst-window=0x04000172 src-x=1250 src-y=241
000:>:04d0:32: Reply to TranslateCoordinates: same-screen=true(0x01) child=None(0x00000000) dst-x=1123 dst-y=132

X11 protocol is far away in my studies, so maybe it's OK to query for the pointer every CPU tick ;) but that seems pretty weird to me.

Btw, there are few RENDER-Request(149,20): AddGlyphs in the log stream.

There might be a problem in the way a Qt Widget behaves/is used (eg, to show some tooltip or subwidget).

Best regards,

Stéphane

comment:38 by Frank Mehnert, 12 years ago

Description: modified (diff)

Interesting finding. Starting with VirtualBox 4.0, a lot of more X events are exchanged between the GUI and the X server, xtrace clearly shows that. The actual reason is still unknown.

comment:39 by Frank Mehnert, 12 years ago

We have done some attempts to fix this problem. Could you check if this test build fixes that problem or at least improves the behavior? The code is also in the public SVN so updating + recompiling is also possible to test the fixes.

comment:40 by sch_dk, 12 years ago

I can verify the slowness of VirtualBox GUI over ssh, and I have a different setup:

Server: FreeBSD 9.0 i386 with xorg-minimal anf virtualbox-ose build from ports with qt4, using openssh

virtualbox-ose-4.1.14
xorg-minimal-7.5.2
qt4-corelib-4.7.4 

I've used two clients to access the GUI (using ssh -X)

Client1: Mac OSX Lion
Client2: Cygwin/X under Windows 7

The GUI works fine, but each event (click/scroll/buttonpress etc) takes 30 sec or more to process in the GUI. Server and Clients have lots of free CPU.

This should clarify that the choice of X server/client isn't a factor.

Since I run all my virtual servers headless, this is purely a "it would be nice if it was fixed"-issue, the main part of VBox is working like a charm for me. Thanks for providing a great product (and the only true virtualization choice on FreeBSD)

comment:41 by Frank Mehnert, 12 years ago

It would be helpful if someone could compile VirtualBox from source and verify if there is an improvement (as I pointed out in my previous comment). I can also provide test builds for specific Linux distributions but I cannot provide a FreeBSD package, sorry.

comment:42 by dokma, 12 years ago

The problem is that all mouse movements get transferred. You can verify this by trying to use the GUI only with keyboard. Probably someone implemented some small fancy improvement in the Manager GUI that requires the mouse position to be tracked all the time, like some onHover type effects.

comment:43 by Frank Mehnert, 12 years ago

Again, we did several improvements in this regards and would appreciate if someone of the reporters could verify this.

in reply to:  43 comment:44 by thoughton, 12 years ago

Replying to frank:

Again, we did several improvements in this regards and would appreciate if someone of the reporters could verify this.

I am not one of the original reporters, but can confirm that using the X11 GUI over SSH (with or without -C) between e.g. Linux host and Mac OS client is extremely slow (I went from 3.2.14 to 4.1.14 to 4.1.16); 3.2 was a lot more responsive. Using keyboard-only navigation doesn't really make much of a difference.

Is there an Ubuntu 8.04 amd_64 test build I should try instead?

comment:45 by Frank Mehnert, 12 years ago

The changes are not part of the 4.1.16 release. Here is a trunk test build for Ubuntu 8.04.

comment:46 by thoughton, 12 years ago

Whoah. Yes, keep those changes in. Thanks!! (Do you have the extension pack too?)

Perhaps a bug: Because I do not have the correct extension pack, USB and VRDP does not work, so I have to discard the state on those vm's that were running with these enabled and then disable them. ONE of the 6 VM's which I run, refused to turn off USB using the GUI in this new trunk version. Using the CLI 'modifyvm', I was still able to turn it off.

Last edited 12 years ago by thoughton (previous) (diff)

comment:47 by Frank Mehnert, 12 years ago

Thanks for testing! Actually these changes are a bit dangerous, therefore we don't plan to backport them to 4.1.x. So these changes will be available with the next major release.

in reply to:  47 comment:48 by thoughton, 12 years ago

Replying to frank:

Thanks for testing! Actually these changes are a bit dangerous, therefore we don't plan to backport them to 4.1.x. So these changes will be available with the next major release.

No problem, hopefully it won't take too long until it's put into a release version. Now that I am running with the trunk version, I am assuming I cannot freeze the VM's and then downgrade to 4.1.16 unless I also discard their state or shut them down. Is this correct?

comment:49 by Frank Mehnert, 12 years ago

Right, sorry. The 'saved state' is not forward compatible, only backward compatible.

comment:50 by aeichner, 8 years ago

Resolution: obsolete
Status: newclosed

Please reopen if still relevant with a recent VirtualBox release.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use