Bug 872573 - dompmsuspend doesn't work twice
dompmsuspend doesn't work twice
Status: CLOSED NEXTRELEASE
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-02 09:13 EDT by Kamil Páral
Modified: 2016-04-26 09:53 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-16 13:29:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kamil Páral 2012-11-02 09:13:23 EDT
Description of problem:
I am following https://fedoraproject.org/wiki/QA:Testcase_Virtualization_Guest_Suspend_Hibernate .

I can do "virsh dompmsuspend Machine1 --target mem" and resume easily, but just once. After I try to do it for the second time, I receive:

# virsh dompmsuspend Machine1 --target mem
error: Domain Machine1 could not be suspended
error: Guest agent is not responding: QEMU guest agent is not available due to an error


Version-Release number of selected component (if applicable):
host:
libvirt-0.10.2.1-2.fc18.x86_64
libvirt-client-0.10.2.1-2.fc18.x86_64
libvirt-daemon-0.10.2.1-2.fc18.x86_64
libvirt-daemon-config-network-0.10.2.1-2.fc18.x86_64
libvirt-daemon-config-nwfilter-0.10.2.1-2.fc18.x86_64
libvirt-daemon-driver-interface-0.10.2.1-2.fc18.x86_64
libvirt-daemon-driver-lxc-0.10.2.1-2.fc18.x86_64
libvirt-daemon-driver-network-0.10.2.1-2.fc18.x86_64
libvirt-daemon-driver-nodedev-0.10.2.1-2.fc18.x86_64
libvirt-daemon-driver-nwfilter-0.10.2.1-2.fc18.x86_64
libvirt-daemon-driver-qemu-0.10.2.1-2.fc18.x86_64
libvirt-daemon-driver-secret-0.10.2.1-2.fc18.x86_64
libvirt-daemon-driver-storage-0.10.2.1-2.fc18.x86_64
libvirt-daemon-driver-uml-0.10.2.1-2.fc18.x86_64
libvirt-daemon-driver-xen-0.10.2.1-2.fc18.x86_64
libvirt-daemon-kvm-0.10.2.1-2.fc18.x86_64
libvirt-gconfig-0.1.3-1.fc18.x86_64
libvirt-glib-0.1.3-1.fc18.x86_64
libvirt-gobject-0.1.3-1.fc18.x86_64
libvirt-python-0.10.2.1-2.fc18.x86_64
python-virtinst-0.600.3-2.fc18.noarch
virt-manager-0.9.4-3.fc18.noarch
virt-manager-common-0.9.4-3.fc18.noarch
virt-viewer-0.5.4-2.fc18.x86_64

guest:
qemu-kvm-1.2.0-12.fc18.x86_64
qemu-system-x86-1.2.0-12.fc18.x86_64
qemu-guest-agent-1.2.0-19.fc18.x86_64
qemu-common-1.2.0-12.fc18.x86_64
qemu-img-1.2.0-12.fc18.x86_64


How reproducible:
2 of 2 attempts
Comment 1 Kamil Páral 2012-11-02 09:24:45 EDT
I have to power off the guest to get it working again. Rebooting the guest is not enough.
Comment 2 Jiri Denemark 2012-11-05 04:32:36 EST
Well, I think this works as expected. If you suspend a guest OS to memory, all you can do with it is resume or power off. You don't expect anything else from your laptop after suspending it to memory, do you?

The only bug I see is that the error message is quite unclear. We should be able to tell that the guest is already suspended.
Comment 3 Kamil Páral 2012-11-05 04:50:00 EST
No, you don't understand.

suspend -> resume                                              # works
suspend -> resume -> suspend                                   # doesn't work
suspend -> resume -> power off -> start -> suspend -> resume   # works
Comment 4 Jiri Denemark 2012-11-05 04:55:22 EST
Ah, I thought there was no resume between the two suspends. Is the guest otherwise working after resume? Can you ssh to it, for example?
Comment 5 Kamil Páral 2012-11-05 09:27:29 EST
Yes, the guest was working after the resume just fine. I didn't try ssh, but I could use GNOME as usual. But I couldn't suspend it again.
Comment 6 Ján Tomko 2015-03-16 13:29:51 EDT
Multiple suspend -> resume -> suspend cycles worked for me when testing this fix:

commit 723522328f2d92e4c2d5de35b3b3ec0302bb06ac
Author:     Ján Tomko <jtomko@redhat.com>
AuthorDate: 2015-02-26 14:00:47 +0100
Commit:     Ján Tomko <jtomko@redhat.com>
CommitDate: 2015-03-02 08:07:56 +0100

    Check if domain is running in qemuDomainAgentIsAvailable
    
    If the domain is not running, the agent will not respond.
    Do not even try.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=872424

git describe: v1.2.13-20-g7235223

It will be a part of the next upstream release.

Note You need to log in before you can comment on or make changes to this bug.