Description of problem: if I have a guest (CentOS 5, fully updated) set to autostart, then the host will lock up hard after a non-deterministic time. Version-Release number of selected component (if applicable): qemu-kvm-0.11.0-12.fc12.x86_64 qemu-common-0.11.0-12.fc12.x86_64 qemu-kvm-0.11.0-12.fc12.x86_64 qemu-img-0.11.0-12.fc12.x86_64 gpxe-roms-qemu-0.9.7-6.fc12.noarch qemu-system-x86-0.11.0-12.fc12.x86_64 libvirt-python-0.7.1-15.fc12.x86_64 libvirt-0.7.1-15.fc12.x86_64 libvirt-client-0.7.1-15.fc12.x86_64 How reproducible: time seems variable but hang does happen Steps to Reproduce: 1. set a guest to autostart 2. allow libvirtd to start, either at boot or via 'service libvirtd start' 3. wait Actual results: after a while (low minute range, somtime well under a minute) host locks up hard. SysRq in most cases seemingly non-functional (it is on in sysctl.conf). oops printed to console. Expected results: host definitely not locking up, ideally guest also running Additional info: - one of the last thigs to make it to syslog is Jan 26 11:56:55 morn kernel: kvm: 2631: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x130079 Jan 26 11:56:55 morn kernel: kvm: 2631: cpu0 unimplemented perfctr wrmsr: 0xc1 data 0xffd4c590 Jan 26 11:56:55 morn kernel: kvm: 2631: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x530079 - The box in question is http://smolts.org/show?uuid=pub_a09f0cfb-e2f0-46d8-9cf9-b7c452ed53b0 - I only started using autostart a day or two ago on this box, so unsure if older package versions affect this. Booting 2.6.31.9-174.fc12.x86_64 instead of the default 2.6.31.12-174.2.3.fc12.x86_64 does not help - I guess it's time to wire up serial console on the host, I'll try doing that this evening
Created attachment 386796 [details] oops of an autostarting guest oops printed while viewing 'virsh --connect qemu:///system console funambol-test' that guest was being autostarted and the host had issued a 'service libvirtd start' shorty before I know this png is of limited value. Once I have a serial capture, I will replace this attachment
Re-assigning to QEMU component, but this will almost certainly want to be pushed to the kernel eventually.
FWIW: just started the guest manually with 'virsh --connect qemu:///system start funambol-test' and so far the host stayed up
setting this NEEDINFO until I (or someone else) posts an oops in text form. been lazy last two evenings, will try and do the wiring up in the next few days. It could be that conntrack is part of the problem, to be confirmed. FWIW, on the affected box I do use amanda_conntrack
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
you can let this bug die On my Fedora boxes I just went to not autostart hosts a long while ago and I am yet to see this bug on my RHEL boxes.
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.