The bug is reproduced on the recent Fedora versions. I have now F18 host and guest. Steps to reproduce: 1. Run VM 2. Suspend the host machine for a night 3. Resume the machine Host hardware: MacBook Air 5.2. Operating System and Architecture: Linux MBA 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 +++ This bug was initially created as a clone of Bug #710378 +++ I have multiple VMs running in qemu-kvm on F13 x86_64 host machine. If the machine is suspended and resumed after some longer time the F15 x86_64 guest VM is always taking full CPU and does not respond except to ping. The various other VMs (with F14, RHEL5 and RHEL6) run fine. --- Additional comment from Jens Petersen on 2011-06-09 21:30:58 EDT --- Yes rather annoying and has been happening from before F15Beta iirc. --- Additional comment from Jens Petersen on 2011-06-09 21:34:31 EDT --- I don't think the host OS matters much: I have seen it on both F14 and F15 x86_64 hosts, but problem only occurs for F15 guests as Tomas also mentioned (both i686 and x86_64). --- Additional comment from Jens Petersen on 2011-06-09 21:37:05 EDT --- I have tried leaving a "top -b" process running as you once suggested but haven't gotten an useful output yet from that. Is there anything else we can try to get more info on this problem? --- Additional comment from Jens Petersen on 2011-07-07 03:39:52 EDT --- Increasing severity and priority in the hope this might get some attention. Also happens with f16 rawhide guests. --- Additional comment from Jens Petersen on 2011-07-23 09:46:10 EDT --- Oh my rawhide guest resumed now! It is running kernel-3.0-0.rc7.git3.1.fc16.x86_64. --- Additional comment from Tomas Mraz on 2011-07-26 04:02:50 EDT --- It did not for me with kernel-3.0.0-1.fc16.x86_64. So no change here. Although the hang was not complete - ping works, even ssh can connect but not finish the login, gpm on text console can move the mouse cursor but getty does not react to keyboard. --- Additional comment from Jens Petersen on 2011-10-18 03:19:30 EDT --- Yeah I think I was too optimistic too soon: after that I have still seen issues too. --- Additional comment from Jens Petersen on 2011-10-20 20:02:29 EDT --- Happened again for me today with Fedora-16-Nightly-20111019.10-x86_64-Live-desktop guest. --- Additional comment from Ilari Stenroth on 2011-12-10 04:09:26 EST --- I wonder if this is related to guest clock steal time accounting. Linux 3.0-rc6 introduced steal time accounting to KVM. But if this happens with kernels prior 3.0 then it's probably not related to steal time accounting. I don't have a hibernateable system with KVM guests so I can not try out myself. If you will try to boot guest kernel with parameter "no-steal-acc" and see if something changes. --- Additional comment from Tomas Mraz on 2011-12-12 02:51:02 EST --- No, I was seeing it with kernel-2.6.38 already. I'm unsure what version started it with though. --- Additional comment from Tomas Mraz on 2011-12-12 02:54:12 EST --- Also I've always suspected some interaction of kernel with systemd to be the cause because in F14 we had upstart as init. I do not want to say that systemd is the culprit here I'd rather say that systemd does something with kernel that upstart did not do that triggers the bug in kernel. I'll try some distro with upstart init and recent kernel. --- Additional comment from Tomas Mraz on 2011-12-14 03:35:04 EST --- Tried Linux Mint 12 with 3.0.0 kernel and upstart - does not hang. Currently updated F16 still hangs. The possible culprit might be usage of cgroups. Systemd uses them, upstart does not. --- Additional comment from Josh Boyer on 2012-06-06 09:24:31 EDT --- Moving this to F16 for now. Is this still being seen in current F16/F17/rawhide? --- Additional comment from Tomas Mraz on 2012-06-06 09:32:30 EDT --- I did not see the hang recently. So if it happens at all it must be much much less often than before. But I've also changed the host machine hardware so it might be related to this change. --- Additional comment from Josh Boyer on 2012-09-05 09:40:30 EDT --- Closing per comment #15. There were also recent changes to prevent libvirt from getting stuck on one CPU after resume.
Are you still seeing this with the latest F18 updates and kernel 3.9.8 or newer?
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.