[19.10][qemu] virsh dompmwakeup fails to wake VM from dompmsuspend state (kvm)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
The Ubuntu-power-systems project |
Fix Released
|
High
|
Canonical Server | ||
libvirt (Ubuntu) |
Fix Released
|
High
|
Canonical Server | ||
qemu (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
== Comment: #0 - Balamuruhan S <email address hidden> - 2018-03-26 08:32:44 ==
---Problem Description---
virsh dompmwakeup fails to wake VM from dompmsuspend state, VM state remains running instead of pmsuspended even in suspended state. Guest kernel enters to suspend state and qemu/libvirt are not aware of it.
# tail -f /var/log/syslog
Mar 26 08:22:44 ubuntu systemd[1]: Started User Manager for UID 0.
Mar 26 08:23:45 ubuntu systemd-
Mar 26 08:23:45 ubuntu kernel: [ 1802.926114] PM: suspend entry (s2idle)
Machine Type = Boston
---Steps to Reproduce---
1. Start a VM and ensure it reaches login prompt
2. Ensure qemu-guest-agent is available and running in the VM
3. Suspend the VM to mem using virsh dompmsuspend <domain> mem --duration 0
4. VM enters suspended state, try to wake up the VM using virsh dompmwakeup <domain>
5. Libvirt returns that VM got wokeup but ideally it doesn't
# virsh list --all
Id Name State
-------
2 virt-tests-vm1 running
# virsh dompmsuspend virt-tests-vm1 mem
Domain virt-tests-vm1 successfully suspended
# echo $?
0
After dompmsuspend,
# virsh list --all
Id Name State
-------
14 virt-tests-vm1 running
- nrs shut off
# virsh domstate virt-tests-vm1 --reason
running (booted)
---uname output---
Host Kernel
# uname -a
Linux ltc-boston17 4.15.0-12-generic #13 SMP Thu Mar 22 14:16:58 CDT 2018 ppc64le ppc64le ppc64le GNU/Linux
Guest Kernel:
# uname -a
Linux ubuntu 4.15.0-12-generic #13-Ubuntu SMP Wed Mar 7 21:37:03 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux
---Debugger---
A debugger is not configured
Contact Information = Balamuruhan S / <email address hidden>
Userspace tool common name: qemu
Userspace rpm:
Qemu:
# dpkg -l | grep qemu
ii ipxe-qemu 1.0.0+git-
ii ipxe-qemu-
ii qemu-block-
ii qemu-kvm 1:2.11+
ii qemu-slof 20170724+
ii qemu-system-common 1:2.11+
ii qemu-system-ppc 1:2.11+
ii qemu-utils 1:2.11+
Libvirt:
# dpkg -l | grep libvirt
ii libvirt-bin 4.0.0-1ubuntu7 ppc64el programs for the libvirt library
ii libvirt-clients 4.0.0-1ubuntu7 ppc64el Programs for the libvirt library
ii libvirt-daemon 4.0.0-1ubuntu7 ppc64el Virtualization daemon
ii libvirt-
ii libvirt-
ii libvirt-dev:ppc64el 4.0.0-1ubuntu7 ppc64el development files for the libvirt library
ii libvirt-
ii libvirt0:ppc64el 4.0.0-1ubuntu7 ppc64el library for interfacing with different virtualization systems
ii python-libvirt 4.0.0-1 ppc64el libvirt Python bindings
The userspace tool has the following bit modes: ppc64le
Userspace tool obtained from project website: na
*Additional Instructions for Balamuruhan S / <email address hidden>:
-Post a private note with access information to the machine that the bug is occuring on.
-Attach ltrace and strace of userspace application.
tags: | added: architecture-ppc64le bugnameltc-166048 severity-high targetmilestone-inin1804 |
Changed in ubuntu: | |
assignee: | nobody → Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) |
affects: | ubuntu → qemu (Ubuntu) |
Changed in ubuntu-power-systems: | |
importance: | Undecided → High |
status: | New → Triaged |
assignee: | nobody → Canonical Server Team (canonical-server) |
Changed in qemu (Ubuntu): | |
assignee: | Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) → David Britton (davidpbritton) |
importance: | Undecided → High |
tags: | added: triage-a |
summary: |
- Ubuntu18.04 - [qemu] virsh dompmwakeup fails to wake VM from - dompmsuspend state (kvm) + [qemu] virsh dompmwakeup fails to wake VM from dompmsuspend state (kvm) |
Changed in qemu (Ubuntu): | |
status: | New → Incomplete |
summary: |
- [qemu] virsh dompmwakeup fails to wake VM from dompmsuspend state (kvm) + [18.10][qemu] virsh dompmwakeup fails to wake VM from dompmsuspend state + (kvm) |
tags: |
added: targetmilestone-inin1810 removed: targetmilestone-inin1804 |
tags: |
added: targetmilestone-inin1804 removed: targetmilestone-inin1810 |
tags: |
added: triage-g removed: triage-a |
Changed in qemu (Ubuntu): | |
assignee: | David Britton (davidpbritton) → nobody |
Changed in ubuntu-power-systems: | |
status: | Incomplete → Triaged |
Changed in ubuntu-power-systems: | |
assignee: | Canonical Server Team (canonical-server) → Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) |
tags: |
added: libvirt-19.10 removed: libvirt-19.04 |
Changed in libvirt (Ubuntu): | |
status: | Incomplete → Confirmed |
Changed in ubuntu-power-systems: | |
status: | Incomplete → Triaged |
Changed in ubuntu-power-systems: | |
status: | Triaged → Confirmed |
Changed in libvirt (Ubuntu): | |
importance: | Undecided → High |
assignee: | nobody → Canonical Server Team (canonical-server) |
Changed in ubuntu-power-systems: | |
assignee: | Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) → Canonical Server Team (canonical-server) |
summary: |
- [18.10][qemu] virsh dompmwakeup fails to wake VM from dompmsuspend state + [19.10][qemu] virsh dompmwakeup fails to wake VM from dompmsuspend state (kvm) |
Changed in libvirt (Ubuntu): | |
milestone: | none → ubuntu-19.10 |
Changed in libvirt (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in ubuntu-power-systems: | |
status: | Confirmed → Fix Released |
------- Comment From <email address hidden> 2018-03-28 06:24 EDT-------
Note from Daniel, who is looking into this bug.
-----
Quick recap: this problem happens because we don't have the wake-up from software suspend implemented in the pseries machine. In fact, at least last time I checked, only the x86 machines implement it.
I've send patches to the QEMU ML about 3 months ago to implement a new API (well, technically a change in an existing API) to detect whether the guest has this capability or not. The idea is to use it in Libvirt to prevent pm-suspend and similar commands to execute at all if the guest can't proper wake up. The patches were left behind along the way, and now people are working towards the RC releases of 2.12 (i.e just critical bug fixes).
I'll re-re-send that patches aiming for 2.13 and see if we can finally get them upstream.