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.
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 ?
Created attachment 348556 [details] requested files fullvirt-install.tar.gz contains the guest config, xend.log, virt-manager.log and xm dmesg output.
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 or 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.
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.
(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
Almost sounds like power mgmt is kicking in...can you disable it and see how it performs?
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.
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.
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 ? Thanks, Michal
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.
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)
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.
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.
Arg, PARAvirt install took only about 9 minutes, not FV. Things seem to be working okay now.
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
This bug was closed during 5.5 development and it's being removed from the internal tracking bugs (which are now for 5.6).
Clearing out old flags for reporting purposes. Chris Lalancette