This sounds sort of like a problem I have with reverting to live snapshots.
What I found out is that this is related to restoring the clock in the guest.
You can find out more about it there:
https://bugs.launchpad.net/qemu/+bug/1505041
The takeaway is that a workaround is to set track='guest' on the rtc
timer. For instance:
<clock offset='localtime'>
<timer name='rtc' track='guest'/>
</clock>
If you have track='catchup' QEMU seems to try to send millions of
interrupts so the guest clock will catch up to the current time, which
can take minutes during which the guest is unusable.
It is possible this no longer happens though as I have had this
workaround in place for quite some time but nobody formally said this is
fixed or pointed to a commit fixing this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1174654
Title:
qemu-system-x86_64 takes 100% CPU after host machine resumed from
suspend to ram
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1174654/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
