Bug 506838 - Paravirt guest installation extremely slow...unless you move the mouse
Paravirt guest installation extremely slow...unless you move the mouse
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Paolo Bonzini
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2009-06-18 16:30 EDT by Gary Case
Modified: 2010-07-19 09:38 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-30 05:08:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
requested files (13.95 KB, application/x-gzip)
2009-06-18 17:08 EDT, Gary Case
no flags Details

  None (edit)
Description Gary Case 2009-06-18 16:30:27 EDT
Description of problem:
Installing x86_64 paravirt guests on x86_64 RHEL5.3 GA and RHEL5.4 is extremely slow (85-135 minute and higher estimated completion time) unless you click in the guest window and move the mouse continually. That makes it complete at a more reasonable rate.

Version-Release number of selected component (if applicable):
RHEL5.3, RHEL5.4 from 20090608.0 tree

How reproducible:
Every time

Steps to Reproduce:
1. Install PV guest through the gui virt-manager
2. Watch paint dry
3. Guest install completes
Actual results:
Glacial speed

Expected results:
Slower than bare metal install, but not as slow as this is.

Additional info:
Systems tested were Nehalems (Sun Ultra 27, intel SB5500BC) so not slow boxes.

Guests had 6GB storage file, 512MB RAM, installation via HTTP, shared physical device NIC.
Comment 1 Daniel Berrange 2009-06-18 16:41:27 EDT
Please provide more information. Which guest OS is being installed ? 

Also attach 

 - The guest config (virsh dumpxml guest)
 - The /var/log/xen/xend.log file
 - The /root/.virt-manager/virt-manager.log file
 - 'xm dmesg' output

Does the same problem occurr if you use 'virt-install' todo a text mode install ?
Comment 2 Gary Case 2009-06-18 17:08:22 EDT
Created attachment 348556 [details]
requested files

fullvirt-install.tar.gz contains the guest config, xend.log, virt-manager.log and xm dmesg output.
Comment 3 Gary Case 2009-06-18 17:14:58 EDT
The guest OS being installed is the same as the dom0 in both instances:

RHEL 5.4 x86_64 from the 20090608.0 tree for paravirt guest and dom0
RHEL 5.3 x86_64 from the 5.3 GA bits for paravirt guest and dom0

(I'm not mixing versions here)

I'll try the text-tool install and see how that behaves.
Comment 4 Gary Case 2009-06-18 18:37:24 EDT
I'm trying the text-tool installer (5.4 dom0, 5.4 domU x86_64) and it's even slower. I've been sitting for about 10 minutes at the "Starting install process...This may take several minutes" window.
Comment 5 Chris Lalancette 2009-06-19 02:41:35 EDT
(In reply to comment #0)
> Guests had 6GB storage file, 512MB RAM, installation via HTTP, shared physical
> device NIC.  

Hm, this might be part of your problem.  Give the guest more RAM (like 1024MB or more).  x86_64 is known to have problems installing guests with < 768MB of memory (it usually manifests as OOM-kills, but maybe the behavior has changed recently and it is swapping like crazy now).

If that doesn't change anything, please give some detailed information about the test systems, including information on how to access the machine(s).  We've definitely tested on Nehalem without problems, so if it isn't lack of memory in the guest, there has to be something particular about those machines (or the configuration).

Chris Lalancette
Comment 6 Bill Burns 2009-06-19 06:46:56 EDT
Almost sounds like power mgmt is kicking in...can you disable it and see how it performs?
Comment 7 Daniel Berrange 2009-06-19 07:02:54 EDT
I think I'd tend to agree with Chris that amount of RAM is a likely candidate. 512 MB is right on the edge of minimum acceptable RAM for x86_64 + default RPM package list.  HTTP installs require about 70 MB more RAM than NFS based installs, so that's probably a factor. I'd recommend increasing to 700 MB to give a good safety margin.
Comment 8 Paolo Bonzini 2009-07-15 08:02:31 EDT
I'm seeing this with a F10 install on RHEL5.4, 32-bit on 32-bit.  8GB host, 3GB guest (but I tried also with 1GB), 10GB guest drive.  glibc installation took something like 5 minutes alone.  Moving the mouse does not make any difference.

Now trying 32-bit on 64-bit too.
Comment 9 Michal Novotny 2009-08-05 12:04:29 EDT
Do you mean 8 GB host as 8 GB host memory configuration and 3 GB guest as 3 GB allocated for this guest ?

Moving the mouse doesn't make any different? So why are you having "unless you move the mouse" in bug description/name ?

Comment 10 Paolo Bonzini 2009-08-05 17:45:00 EDT
I'm not the original reporter.  I'm seeing very slow installs of F10 too, but unlike the original reporter moving the mouse does not help for me.
Comment 11 Jon Dowland 2009-09-01 11:41:56 EDT
I think this could be entropy related. Something might be blocking on /dev/random and moving the mouse generates more interrupts. Text mode is worse because the mouse is not configured (tapping caps lock repeatedly would achieve the same effect if I'm correct about it being entropy)
Comment 12 Daniel Berrange 2009-09-01 12:04:41 EDT
The original reporter still hasn't responded to the suggestion to increase the RAM beyond 512 MB.   It is well known that attempting installs with only 512 MB of RAM results in all sorts of problems, increasing unbelievably slow progress. It is not worth debugging this issue further unless the orignal reporter reproduces the same problem with a guest with 1 GB of RAM.

As for Paolo's Fedora guest problem, please report that in a separate bug, there are plenty of things that could be wrong with Fedora guests. This should be troubleshooted separately from the original RHEL guest problems which are a completely different Xen guest codebase.
Comment 13 Gary Case 2009-09-29 14:28:58 EDT
Sorry, original reporter here. This looks like it's working well now in 5.4 even with 512MB of RAM. Full-virt install took only about 9 minutes.
Comment 14 Gary Case 2009-09-29 14:29:42 EDT
Arg, PARAvirt install took only about 9 minutes, not FV. Things seem to be working okay now.
Comment 15 Chris Lalancette 2009-09-30 05:08:45 EDT
OK, thanks for responding Gary.  Hard to say what changed, since we couldn't reproduce it ourselves and we didn't put any specific patches in to fix this.  Nevertheless, I'm going to close the bug.  Feel free to re-open it if the problem pops up again.

Chris Lalancette
Comment 16 Paolo Bonzini 2010-04-08 11:44:02 EDT
This bug was closed during 5.5 development and it's being removed from the internal tracking bugs (which are now for 5.6).
Comment 17 Chris Lalancette 2010-07-19 09:38:56 EDT
Clearing out old flags for reporting purposes.

Chris Lalancette

Note You need to log in before you can comment on or make changes to this bug.