Interesting, so the main qemu in the host consumes ~17% user and ~18%
system while this is going on. And this goes on for at least the 15
seconds we traced things (and from your report I assume it keeps going
on).
We also see context switches, but no faults - this really just seems to "do
something".
Very odd and very unexpected @pedro.
Nothing is spend in the guest, matching what you'd expect after pausing.
I'd understand some buffer flushes or cleanups but those should stop after a
while.
But if you say this "keep going" I agree that it feels odd.
With these logs I'd at least call it confirmed for now.
But it seems we need to go step by step analazing what is going on.
The next obvious step once you again see such a case would be to check
"what" the qemu is doing on the host.
I'm not sure how experienced you are with profiling workload.
If you are please just dive deep and report what you find.
If you are not I can give suggestions every step but we will have to ping/pong
this back and forth until we have something.
When in this paused-but-busy state you could next time run:
$ sudo strace -rT -ff -f -o paused-but-busy -p $(pidof qemu-system-x86_64)
Please at the same time also run the other one you already used so that we can
match thread IDs:
$ pidstat -p $(pidof qemu-system-x86_64) -T ALL -rtuw 5 5
Also with the guest paused I'd expect the following not to move:
for i in $(seq 1 5); do virsh domstats "<yourguestname>"; sleep 5; done
** Changed in: qemu (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1851062
Title:
Qemu using CPU even when the VM is paused
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1851062/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
