VirtualBox

Ticket #8175 (new defect)

Opened 3 years ago

Last modified 23 months ago

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

Reported by: uli100 Owned by:
Priority: major Component: GUI
Version: VirtualBox 4.0.2 Keywords:
Cc: Guest type: other
Host type: Linux

Description (last modified by frank) (diff)

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

comment:1 Changed 3 years ago by uli100

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 Changed 3 years ago by uli100

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 Changed 3 years ago by tomtom

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 Changed 3 years ago by Technologov

Added myself as CC to this issue.

-Technologov

comment:5 Changed 3 years ago by frank

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 Changed 3 years ago by uli100

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 Changed 3 years ago by tomtom

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 Changed 3 years ago by ostkamp

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 Changed 3 years ago by vgnaras

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

comment:10 Changed 3 years ago by diver

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

comment:11 Changed 3 years ago by tomtom

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

comment:12 Changed 3 years ago by Technologov

Not listed in changelog, so not fixed.

-Technologov

comment:13 Changed 3 years ago by wlet

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

comment:14 Changed 3 years ago by ariel

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 Changed 3 years ago by frank

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 Changed 3 years ago by tomtom

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 Changed 3 years ago by uli100

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 Changed 3 years ago by frank

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

comment:19 Changed 3 years ago by uli100

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 Changed 3 years ago by frank

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

comment:21 Changed 3 years ago by uli100

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 Changed 3 years ago by frank

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

comment:23 Changed 3 years ago by tomtom

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

comment:24 Changed 3 years ago by Technologov

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

-Technologov

comment:25 Changed 3 years ago by uli100

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 Changed 3 years ago by ostkamp

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 Changed 3 years ago by tomtom

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 Changed 3 years ago by Technologov

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 Changed 3 years ago by ostkamp

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 Changed 3 years ago by josh@…

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 Changed 3 years ago by Kari

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 Changed 3 years ago by Zarquan

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 Changed 3 years ago by jlugert

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

Jerry

comment:34 Changed 3 years ago by tomtom

@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 Changed 3 years ago by tomtom

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 Changed 3 years ago by O.J.

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

comment:37 Changed 2 years ago by smariel

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 Changed 2 years ago by frank

  • 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 Changed 2 years ago by frank

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 Changed 2 years ago by sch_dk

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 Changed 2 years ago by frank

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 Changed 23 months ago by dokma

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 follow-up: ↓ 44 Changed 23 months ago by frank

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

comment:44 in reply to: ↑ 43 Changed 23 months ago by thoughton

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 Changed 23 months ago by frank

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

comment:46 Changed 23 months ago by thoughton

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 23 months ago by thoughton (previous) (diff)

comment:47 follow-up: ↓ 48 Changed 23 months ago by 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.

comment:48 in reply to: ↑ 47 Changed 23 months ago by thoughton

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 Changed 23 months ago by frank

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

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use