Description of problem: Trying to run the live install of F18 as a kvm guest on a RHEL 5.9 KVM host, and the resulting KVM guest is using 100%cpu most of the time, and is extremely slow, other running KVM guests have no problems. In the vncviewer of the F18 KVM guest, I get: the Live System User prompt then grey screen then after too long (1-2 mn), screen for "Try Fedora" or "Install to Hard Drive" then after too long (1-2 mn), 100% 1 cpu, screen for "WELCOME..." lang selection click Continue, then seem to hang with 100% cpu use another grey screen after 1 mn, till 100% cpu use then "INSTALL..SUMMARY" tab tab to reach "DATE&TIME" too long and 100% cpu use, grey screen, then 0% cpu, but nothing else than grey screen then grey screen, nothing seem to happen, 0%cpu I have been using other guests without such problems. Trying on a RHEL 6 KVM host is sightly better but till very slow, the KVM host has no problems running other KVM guests. Version-Release number of selected component (if applicable): F18 KVM guest from: http://download.fedoraproject.org/pub/fedora/linux/releases/18/Live/x86_64/Fedora-18-x86_64-Live-Desktop.iso running on KVM host with: Red Hat Enterprise Linux Server release 5.9 (Tikanga) Linux mstest0.example.com 2.6.18-348.el5 #1 SMP Wed Nov 28 21:22:00 EST 2012 x86_64 x86_64 x86_64 GNU/Linux kvm-83-164.el5_5.21 kvm-qemu-img-83-164.el5_5.21 the guest runs like this: 24201 ? Sl 0:55 /usr/libexec/qemu-kvm -S -M rhel5.4.0 -m 1024 -smp 1 -name f18test -uuid 543b2070-4c3d-47c9-b05d-061bc86bf200 -no-kvm-pit-reinjection -monitor pty -pidfile /var/run/libvirt/qemu//f18test.pid -boot d -drive file=/dev/vg0/f18test,if=ide,index=0,cache=none -drive file=/bak/iso/fedora/Fedora-18-x86_64-Live-Desktop.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:2f:14:d2,vlan=0,model=pcnet -net tap,fd=15,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-us and uses the vga cirrus driver How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Definitely not seen this. What happens if you bump the memory in your VM up by a bit? Running the live environment and doing an install is pretty memory-intensive.
Here are some times on an F18 host: isolinux menu -> gdm login: 29 sec. gdm login -> gnome desktop with "Install ..." button: 14 sec. "Install ..." button -> installer Welcome: 12 sec. Tested with: $ qemu-kvm -m 1024 -cdrom ~/xfr/fedora/F18/F18-Final/Final/Fedora-18-x86_64-Live-Desktop.iso -vga std -boot menu=on -vnc localhost:0 $ vncviewer localhost $ rpm -q qemu-kvm tigervnc qemu-kvm-1.2.2-4.fc18.x86_64 tigervnc-1.2.80-0.6.20121126svn5015.fc18.x86_64 $ sha256sum Fedora-18-x86_64-Live-Desktop.iso a276e06d244e04b765f0a35532d9036ad84f340b0bdcc32e0233a8fbc31d5bed Fedora-18-x86_64-Live-Desktop.iso
(In reply to comment #0) ... > the Live System User prompt > then grey screen > then after too long (1-2 mn), screen for "Try Fedora" or "Install to Hard > Drive" ... The installer isn't running here, so this doesn't seem like an installer problem. Have you tried running from the command line with default qemu-kvm options? $ qemu-kvm -m 1024 -cdrom /bak/iso/fedora/Fedora-18-x86_64-Live-Desktop.iso
Confirming in both first Fedora KDE Test Composes. The desktop environment itself is perfectly fine but every action (like clicking a button, transition to another screen...) in the installer takes tens of seconds, maybe minutes and drives the CPU usage very high, to almost 100% on two cores out of four. Ran in qemu-kvm from virt-manager with the following commandline: /usr/bin/qemu-kvm -name F19 -S -M pc-1.2 -enable-kvm -m 2048 -smp 4,sockets=4,cores=1,threads=1 -uuid c142b060-b3b3-879a-a097-fcb3ce92852e -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/F19.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/dev/mapper/vg_dhcp2130-f19,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/home/mbriza/Fedora-19-Alpha-TC2-x86_64-Live-KDE.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:7f:66:3e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
(In reply to comment #4) > Confirming in both first Fedora KDE Test Composes. ... > Ran in qemu-kvm from virt-manager with the following commandline: ... Thanks for your report. For completeness, could you report your host and the versions? $ uname -a $ rpm -q qemu-kvm virt-manager
Hi, it is: Linux mbriza-laptop.usersys.redhat.com 3.8.4-202.fc18.x86_64 #1 SMP Thu Mar 21 17:02:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux qemu-kvm-1.2.2-7.fc18.x86_64 virt-manager-0.9.4-4.fc18.noarch Also, just out of curiosity, I ran qemu-kvm -m 1024 -cdrom /home/mbriza/Fedora-19-Alpha-TC2-x86_64-Live-KDE.iso and it's stuck on a black screen with a mouse cursor for a few minutes, can't tell if it's still booting or this is the final state. Will report here if it finishes eventually.
Can you strace anaconda and see whether we're hung up waiting on something?
Created attachment 717683 [details] Repeated pattern in strace when anaconda is stuck There's this (or similar) pattern periodically repeating every time any UI action in anaconda is done. By the way, the VM I mentioned in the previous message still didn't boot fully, I can move the mouse cursor and there was a gray stripe on the bottom for a while but nothing more...
The original report indicates the live environment is running extremely slowly, too, not just anaconda. Reassigning first to kvm, though I'm sure they will want to reassign in turn.
kvm is an unused component, it's qemu now. This report is all over the place. Some people are on RHEl5 host, others on F18. Some people are using F18 media, others F19 composes. Some are using libvirt, others straight qemu command line. Some are using 1G ram, others more. I'll just stick with mbriza's report. Martin, can you still reproduce with a libvirt created guest and F19 alpha? Can you try bumping the ram up to 4G to fully remove that potential factor? Also make sure your F18 guest is fully up to date. See if any KVM errors in host dmesg.
Created attachment 741832 [details] commandline Cole, it's still present with the KDE Spin of Fedora 19 Alpha in virt-manager guest (hope that's what "libvirt created quest" means) with 4G of RAM. Host is fully (yesterday) updated Fedora 18: qemu-kvm-1.2.2-11.fc18.x86_64 libvirt-0.10.2.4-1.fc18.x86_64 virt-manager-0.9.5-1.fc18.noarch Dmesg is clean. Just to reiterate, it's anaconda what is slow, not the environment. While the installer is stuck, I can for example open Kickoff (the main menu) of KDE with regular (in terms of virtual machines) response time. Speed difference of scrolling through the lists is also very significant, in KDE dialogs, the menus are smooth and scroll immediately, however in anaconda, the scrolling is lagging and animations aren't smooth. I didn't experience this behavior in anaconda ran from the netinstall ISO.
mbriza, sorry I never followed up with your last comment. I'm interested in if this still reproduces with up to date F18 and F19 GA installer. Please list f18 kernel version if so.
Hi Cole, unfortunately I have reinstalled my OS recently and can't use virt-manager at all (gets stuck connecting to QEMU) to set up similar environment as I have had. When I'm able to use it again, I'll be glad to provide information on how are thing standing now.
Hi Cole, after today's update of libvirt* packages in F19 virt-manager got finally connected to QEMU so I could test. The situation is a lot better (can't tell if it's caused by the fact I reinstalled the OS or not) yet it isn't a completely smooth experience. Especially the disk partitioning (set the whole disk to be used for /) and the nag (warning message about not having a swap partition) opening in the disk dialog afterwards and creating a new user is sluggish.
Okay, just closing this issue then. That first issue sounds anaconda specific. 'sluggishness' might be anaconda as well but we'd need more info and a separate report to determine it, if you think it's severe enough.
(In reply to Martin Bříza from comment #13) > ... I have reinstalled my OS recently ... Could you post all the details again? (For the sluggishness problem, not anaconda GUI design issues.) 1. Fedora image you are running. 2. qemu command line (for amount of memory in particular). 3. Guest disk configuration at startup (for amount of swap in particular). $ lsblk -mf # This gives a very wide report, so an attachment would be best. 4. Host version info: $ uname -a $ rpm -q qemu-kvm virt-manager NB: The anaconda developers will want to see the installer logs. They should be in /tmp before rebooting and in /var/log/anaconda after rebooting. If you believe the sluggishness is anaconda-specific, it would be better to open a new bug against anaconda, as Cole suggests. Cole: Could this qemu option cause sluggishness? "-smp 4,sockets=4,cores=1,threads=1" (from Comment 4)
Created attachment 779906 [details] The commandline
> Cole: Could this qemu option cause sluggishness? > "-smp 4,sockets=4,cores=1,threads=1" (from Comment 4) Not sure why it would, smp VMs are pretty well tested. That's the default topology if you specify 4 vcpus in virt-manager, and what qemu always did before it allowed specifying topology.
Created attachment 779909 [details] Distorted windows Fedora image is Fedora-Live-KDE-x86_64-19-1.iso. The disk configuration is just a live image with a 20GB vda disk. Will give a detailed output if you'll request (wrong firewall settings) but it's contained in the screenshot if you don't need to have it in text form. Host info: Linux mbriza-laptop.usersys.redhat.com 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux qemu-kvm-1.4.2-4.fc19.x86_64 virt-manager-0.10.0-1.fc19.noarch I'm suspecting the QXL driver a bit. Today, the VM froze two or three times with it and works just fine with the VGA one. In this boot of a new machine, I even have distorted windows with it (see the screenshot). Also, not really sure if it's related and have no idea how to debug but performance of this computer is really strange. Also it might be my personal opinion but who knows. The computer is just slow, often I have about 20% load in the sy measure in top, not a clue why. Also, doing anything CPU-intensive like compilation, system update or virtual machine install renders the computer basically unusable, with response times in seconds. I never experience anything like this on my personal laptop that has CPU weaker by an order of magnitude... Possibly something wrong there? I don't know and once again, am clueless.
(In reply to Martin Bříza from comment #19) ... > The computer is just slow, ... ... Well, a VM isn't going to work any better than the host, that's for sure ... :-) Could you attach these for your host? 1. dmesg 2. /proc/cpuinfo Anything else, Cole?
Created attachment 779957 [details] /proc/cpuinfo Yeah, you're right it won't be any better but the environment is perfectly fine anyway, with the slowness I was referring especially to the high-load situations. The dmesg output is here: http://ur1.ca/et75y It's a Sandy Bridge i7 dualcore. I think it should be more than enough powerful to run KDE in a virtual machine.
(In reply to Martin Bříza from comment #21) > Created attachment 779957 [details] > /proc/cpuinfo Thanks, that looks fine: ... model name : Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz ... flags : ... vmx ... ... http://www.linux-kvm.org/page/FAQ#How_can_I_tell_if_I_have_Intel_VT_or_AMD-V.3F > Yeah, you're right it won't be any better but the environment is perfectly > fine anyway, with the slowness I was referring especially to the high-load > situations. > > The dmesg output is here: http://ur1.ca/et75y It would be better to attach it, so it remains with the bug report, but I was mainly looking for the amount of memory and swap: $ free > It's a Sandy Bridge i7 dualcore. I think it should be more than enough > powerful to run KDE in a virtual machine. Yes, your CPU is fine, and it supports virtualization (vmx flag). That isn't the problem ... > Linux mbriza-laptop.usersys.redhat.com 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux There is a newer kernel: $ sudo repoquery kernel kernel-0:3.10.3-300.fc19.x86_64 $ sudo yum update
(In reply to Steve Tyler from comment #22) ... > > It's a Sandy Bridge i7 dualcore. I think it should be more than enough > > powerful to run KDE in a virtual machine. > > Yes, your CPU is fine, and it supports virtualization (vmx flag). > That isn't the problem ... The i7-2620M also has Hyper-Threading and Turbo Boost to 3.4 GHz: http://ark.intel.com/products/52231/Intel-Core-i7-2620M-Processor-%284M-Cache-up-to-3_40-GHz%29 Some BIOSes disable virtualization by default, but I don't know if the vmx flag would be reported or not in /proc/cpuinfo, if it were disabled. Cole? Could you please either attach dmesg or post the output of "free" (on your host), so we can also know your host memory and swap configuration? I don't see any reason to follow an offsite link for your dmesg and won't look at it unless it is attached to this bug report. VMs are sensitive to the amount of host memory -- the rule is byte-for-byte: You need a byte of host memory for each byte of VM memory in addition to whatever memory is required for everything else you have running on your host.
(In reply to Steve Tyler from comment #23) ... > Could you please either attach dmesg or post the output of "free" (on your > host), so we can also know your host memory and swap configuration? ... Even better would be a screenshot of "top" running on your host while KDE Live is running in a VM. That will show host memory, host swap, and VM memory usage. Your qemu command-line attachment shows VM memory is 2048 MB ("-m 2048"), so we already know that, but it would good to confirm it while your VM is running.
(In reply to Steve Tyler from comment #24) ... > Even better would be a screenshot of "top" running on your host while KDE > Live is running in a VM. ... After starting "top", press "M" to sort processes by memory usage.
KDE Live in a VM with 2GB memory and no swap is acceptably responsive. Here are two timings: 1. "Start Fedora Live" menu item to KDE desktop: 41 seconds KDE doesn't have a crisp timing point, so wait for the available devices window to disappear. Repeat at least once to fill host disk cache. 2. installer startup to Welcome page: 8 seconds Tested with: $ qemu-img create f19-test-2.img 19.5G $ qemu-kvm -m 2048 -hda f19-test-2.img -cdrom ~/xfr/fedora/F19/Fedora-Live-KDE-x86_64-19-1.iso -vga std -boot menu=on On host: $ uname -a Linux walnut 3.10.3-300.fc19.x86_64 #1 SMP Fri Jul 26 00:00:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ rpm -q qemu qemu-1.4.2-4.fc19.x86_64 $ free total used free shared buffers cached Mem: 12049040 6394044 5654996 0 102772 3089328 -/+ buffers/cache: 3201944 8847096 Swap: 1048756 0 1048756 $ egrep 'processor|model name' /proc/cpuinfo processor : 0 model name : AMD Athlon(tm) II X2 260 Processor processor : 1 model name : AMD Athlon(tm) II X2 260 Processor
(In reply to Steve Tyler from comment #26) ... > 2. installer startup to Welcome page: 8 seconds ... That's on the first run. Subsequent runs are about 5 seconds. (I forgot to follow my own advice ... :-))
(In reply to Cole Robinson from comment #18) > > Cole: Could this qemu option cause sluggishness? > > "-smp 4,sockets=4,cores=1,threads=1" (from Comment 4) > > Not sure why it would, smp VMs are pretty well tested. That's the default > topology if you specify 4 vcpus in virt-manager, and what qemu always did > before it allowed specifying topology. OK, that's good to know. I measure a noticeable increase in times when going from 1 to 4 simulated processors on a dual core processor (no hyper-threading). 1. "Start Fedora Live" menu item to KDE desktop: -smp 1: 42 seconds -smp 4: 60 seconds 2. installer startup to Welcome page: 8 seconds -smp 1: 5 seconds -smp 4: 7 seconds Tested with: $ qemu-kvm -m 2048 -hda f19-test-2.img -cdrom ~/xfr/fedora/F19/Fedora-Live-KDE-x86_64-19-1.iso -vga std -boot menu=on -smp 4 $ rpm -q qemu qemu-1.4.2-4.fc19.x86_64
Created attachment 780162 [details] screenshot showing "top" running on KDE Live VM and on host; sorting is by memory ("M") Tested with: $ qemu-kvm -m 2048 -hda f19-test-2.img -cdrom ~/xfr/fedora/F19/Fedora-Live-KDE-x86_64-19-1.iso -vga std -boot menu=on -smp 4
(In reply to Martin Bříza from comment #19) > Created attachment 779909 [details] > Distorted windows I believe that is just line-wrap -- "lsblk -mf" output is very wide. ... > The computer is just slow, often I have about 20% load in the sy measure in > top, not a clue why. Also, doing anything CPU-intensive like compilation, > system update or virtual machine install renders the computer basically > unusable, with response times in seconds. ... Is there a tech support person at work who could check it out? Are the BIOS settings at their defaults? I have zero experience with turbo-boost, but can you disable it in the BIOS?[1] Have you installed any non-Fedora components, such as video drivers or desktop extensions, etc.? [1] Googling "fedora kernel turboboost" might give you some ideas: http://forums.fedoraforum.org/showthread.php?t=280341
Petr Šabata, in Bug 629097, Comment 1, has some info re Turbo Boost and refers to this tool: i7z.x86_64 : CLI curses based monitoring tool for Intel Core i7 processors I just tried it. It displays your CPU core speeds in real time in an ncurses window. Must be run as root. The Fedora package has a man page and README.[1] He also says Turbo Boost is BIOS controlled -- have you checked for a BIOS update? [1] $ sudo repoquery i7z i7z-0:0.27.2-6.fc19.x86_64
Created attachment 780358 [details] Dmesg Steve, first, thanks for the extensive insight! (In reply to Steve Tyler from comment #30) > (In reply to Martin Bříza from comment #19) > > Created attachment 779909 [details] > > Distorted windows > > I believe that is just line-wrap -- "lsblk -mf" output is very wide. I meant how you can see the "FEDORA 19 INSTALLATION" text through the titlebar of the konsole window. I haven't done anything about any relevant BIOS settings. I'm thinking about contacting the tech support but I'm not really thrilled by the idea. Thanks for the links about turboboost, I'll try reading something about it but it doesn't seem like an issue here at the first glance. And the only non-Fedora components here are some packages from Rpmfusion, especially for music playback. Startup times are quite similar to yours, mostly just a few seconds longer. The problem then are the response times in Anaconda. For example the window that appears after you remove the only keyboard layout that is set by default for the US English installation (e.g. the US layout) appears after about 5 seconds. Every other action is slow, too, but bareably, max. 1s per action usually. I attached the dmesg output as you requested and free -m: total used free shared buffers cached Mem: 7869 7671 197 0 283 2219 -/+ buffers/cache: 5168 2700 Swap: 7951 6 7945 It's also worth noting the system load is currently at about 1.5%.
Thanks for the dmesg: [ 0.000000] DMI: LENOVO 4243BQ9/4243BQ9, BIOS 8AET51WW (1.31 ) 08/08/2011 That appears to be a Lenovo ThinkPad T520. There doesn't seem to be a permalink, but this might work: http://support.lenovo.com/en_US/landing.page?qpq=4243BQ9 The 1.43 appears to be the BIOS version: BIOS Update CD 8auj24us.iso 1.43 30 May 2013 (Click "Drivers and Software", "BIOS") There is a changelog about half-way down here: http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/8auj24uc.txt This looks interesting: :-) <1.32> UEFI: 1.32 / ECP: 1.18 - (New) Improved system performance when a heavy software was executed with the 65W AC adapter.
(In reply to Martin Bříza from comment #32) > Created attachment 780358 [details] > Dmesg > > Steve, > first, thanks for the extensive insight! > (In reply to Steve Tyler from comment #30) > > (In reply to Martin Bříza from comment #19) > > > Created attachment 779909 [details] > > > Distorted windows > > > > I believe that is just line-wrap -- "lsblk -mf" output is very wide. > > I meant how you can see the "FEDORA 19 INSTALLATION" text through the > titlebar of the konsole window. ... Thanks, I didn't notice that. I can't reproduce it. If you can reproduce it, could you open a new bug against KDE? (I'm guessing about the component.)
(In reply to Martin Bříza from comment #32) ... > I haven't done anything about any relevant BIOS settings. I'm thinking about > contacting the tech support but I'm not really thrilled by the idea. > Thanks for the links about turboboost, I'll try reading something about it > but it doesn't seem like an issue here at the first glance. > And the only non-Fedora components here are some packages from Rpmfusion, > especially for music playback. OK, but I believe it would be a good idea to update your BIOS (Comment 33). > Startup times are quite similar to yours, mostly just a few seconds longer. > The problem then are the response times in Anaconda. For example the window > that appears after you remove the only keyboard layout that is set by > default for the US English installation (e.g. the US layout) appears after > about 5 seconds. Every other action is slow, too, but bareably, max. 1s per > action usually. I am not seeing any latency between removing the "English (US)" keyboard layout and the display of the "ADD A KEYBOARD LAYOUT" dialog: 1. Do you see any latency when KDE Live is booted from a DVD or USB stick on your host? 2. Have you tried running qemu-kvm from the command line? Tested with: $ qemu-img create f19-test-2.img 19.5G $ qemu-kvm -m 2048 -hda f19-test-2.img -cdrom ~/xfr/fedora/F19/Fedora-Live-KDE-x86_64-19-1.iso -vga std -boot menu=on > I attached the dmesg output as you requested and free -m: > total used free shared buffers cached > Mem: 7869 7671 197 0 283 2219 > -/+ buffers/cache: 5168 2700 > Swap: 7951 6 7945 > > It's also worth noting the system load is currently at about 1.5%. Thanks. That all looks fine.
Created attachment 780932 [details] qemu command line while running virt-manager After trying four VM video devices, I agree that qxl has a noticeably greater latency than the other three. Delete "English (US)" -> "Add a Keyboard Layout": virt-manager: cirrus: ~1 second qxl: 2-3 seconds vga: ~1 second vmvga: ~1.5 seconds xen: not tested Bare metal boot from DVD: no noticeable latency except when the DVD is accessed VM has 2048 MB memory. Fedora-Live-KDE-x86_64-19-1.iso virt-manager-0.10.0-1.fc19.noarch libvirt-1.0.5.4-1.fc19.x86_64 qemu-1.4.2-4.fc19.x86_64 Linux walnut 3.10.3-300.fc19.x86_64 #1 SMP Fri Jul 26 00:00:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Host has 12 GB memory and 1 GB swap: $ free -m total used free shared buffers cached Mem: 11766 5103 6663 0 129 1756 -/+ buffers/cache: 3217 8548 Swap: 1024 0 1024 $ egrep 'processor|model name' /proc/cpuinfo processor : 0 model name : AMD Athlon(tm) II X2 260 Processor processor : 1 model name : AMD Athlon(tm) II X2 260 Processor
Once again, thank you for the extensive insight. You're right I should update my BIOS which I'll do some time soon... The times are indeed somewhat longer with qxl. Anyway, I tried the commands you provided in comment 35 and the overall responsiveness was a huge deal better than when the VM was ran from virt-manager with the commands I listed in my previous comments. It's still not as smooth as in GNOME or netinst images though, in my opinion but however I don't have any way how to measure it accurately. When I run the installer from the KDE live image, there is no noticeable delay. To the graphical glitch - I can't reproduce it again, unfortunately. I think there was a report for a similar problem about a year ago...
(In reply to Martin Bříza from comment #37) > Once again, thank you for the extensive insight. You're right I should > update my BIOS which I'll do some time soon... Soon, I hope ... :-) > The times are indeed somewhat longer with qxl. Anyway, I tried the commands > you provided in comment 35 and the overall responsiveness was a huge deal > better than when the VM was ran from virt-manager with the commands I listed > in my previous comments. It's still not as smooth as in GNOME or netinst > images though, in my opinion but however I don't have any way how to measure > it accurately. ISTM, this might be worth investigating further. VM's always have some overhead, but they should not have noticeable latency in the GUI response, because that affects useability. Using strace or qemu, it might possible to get more accurate and consistent timings. Googling "qemu event timing": http://wiki.qemu.org/Features/Tracing http://www.linux-kvm.org/page/Virtio/Block/Latency (not GUI, though) Cole, is GUI latency worth investigating further? (With a new bug.) > When I run the installer from the KDE live image, there is no noticeable > delay. On a DVD or a USB stick? > To the graphical glitch - I can't reproduce it again, unfortunately. I think > there was a report for a similar problem about a year ago... From my experiments, it looks like KDE enables transparency for the title bar while the window is moving and disables transparency when the window stops moving.
Called "UI lag" here: Former Google intern explains why UI lag occurs more often in Android than iOS http://forums.appleinsider.com/t/137684/former-google-intern-explains-why-ui-lag-occurs-more-often-in-android-than-ios
(In reply to Steve Tyler from comment #38) > (In reply to Martin Bříza from comment #37) > > Once again, thank you for the extensive insight. You're right I should > > update my BIOS which I'll do some time soon... > > Soon, I hope ... :-) Me too :) I'll report if there are any changes when I've done it, some time this week I hope. Anyway, particularly the item with 65W adapter doesn't seem to be the one... I'm running in a dock with a 135W adapter and the laptop doesn't have a dedicated graphics card so it seems sufficient. > > When I run the installer from the KDE live image, there is no noticeable > > delay. > > On a DVD or a USB stick? USB stick. > > To the graphical glitch - I can't reproduce it again, unfortunately. I think > > there was a report for a similar problem about a year ago... > > From my experiments, it looks like KDE enables transparency for the title > bar while the window is moving and disables transparency when the window > stops moving. That's true but as I said, I couldn't reproduce it again unfortunately. > ISTM, this might be worth investigating further. VM's always have some > overhead, but they should not have noticeable latency in the GUI response, > because that affects useability. Using strace or qemu, it might possible to > get more accurate and consistent timings. > > Googling "qemu event timing": > http://wiki.qemu.org/Features/Tracing > http://www.linux-kvm.org/page/Virtio/Block/Latency (not GUI, though) > > Cole, is GUI latency worth investigating further? (With a new bug.) (In reply to Steve Tyler from comment #39) > Called "UI lag" here: > > Former Google intern explains why UI lag occurs more often in Android than > iOS > http://forums.appleinsider.com/t/137684/former-google-intern-explains-why-ui- > lag-occurs-more-often-in-android-than-ios To me, this report wasn't about the UI lag in QEMU as a whole but anaconda particularly because it is noticeably slower than the rest of the environment it is running in and because its performance seems worse in KDE spin than in the others.
Thanks for your followup report, Martin. Anaconda could be doing something that is especially inefficient when running in KDE Live on a VM. Since you have a good reference point with your USB stick and a good test case with your keyboard config test, a new bug against anaconda would be justified. Could you open a new bug and post a link in this bug? strace might show what is going on. There is an example that worked very well for another problem at the end of Bug 974383, Comment 26. Your laptop config doesn't sound like it quite fits the cases fixed by the BIOS updates, but there is no way to know for sure without updating the BIOS or contacting tech support.