This is result of us not checking the state of domain when executing qemuDomainPMSuspendForDuration(). The proper fix is to check it after we obtain job and before we start talking to qemuAgent.

Currently, there is no such check and with current implementation we send something like ping to guest agent to tell if it's there or not (this is done with timeout though). And since domain is in s3 state, the guestAgent won't reply, we timeout and report the error about unavailable guest agent.

This bug was not selected to be addressed in Red Hat Enterprise Linux 6. We will look at it again within the Red Hat Enterprise Linux 7 product.

Upstream patches:
https://www.redhat.com/archives/libvir-list/2015-February/msg01219.html

commit 723522328f2d92e4c2d5de35b3b3ec0302bb06ac
Author:     Ján Tomko <jtomko>
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

Verify this bug with libvirt-1.2.15-2.el7.x86_64, Verify steps as following
1.Start a guest agent configured, After guest start successfully, we could see the guest agent stay in "connected" status.

# virsh start 7.0
Domain 7.0 started

# virsh dumpxml 7.0 |grep agent -A3
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/7.0.org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
      <alias name='channel1'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>

2.Do S3 with the guest, Then the guest agent will run into "disconnected".
# virsh dompmsuspend 7.0 --target mem
Domain 7.0 successfully suspended
# virsh list
 Id    Name                           State
----------------------------------------------------
 33    7.0                            pmsuspended

# virsh dumpxml 7.0 |grep agent -A3
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/7.0.org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
      <alias name='channel1'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>

3.Re-excute S3 or other commands which depends on guest agent, all of them could get expect error
# virsh dompmsuspend 7.0 --target mem
error: Domain 7.0 could not be suspended
error: Guest agent is not responding: QEMU guest agent is not connected

# virsh dompmsuspend 7.0 --target disk
error: Domain 7.0 could not be suspended
error: Guest agent is not responding: QEMU guest agent is not connected

# virsh domtime 7.0
error: Guest agent is not responding: QEMU guest agent is not connected

4.Wakeup the guest, the guest agent's state will come back to "connected" status, also we could scuccessfully excute the virsh commands which depends on guest agent

# virsh dompmwakeup 7.0
Domain 7.0 successfully woken up
# virsh list
 Id    Name                           State
----------------------------------------------------
 33    7.0                            running

# viursh dumpxml 7.0
-bash: viursh: command not found
[root@zhwangrhel71 ~]# virsh dumpxml 7.0 |grep agent -A3
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/7.0.org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
      <alias name='channel1'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>

# virsh domtime 7.0 --pretty
Time: 2015-05-27 06:01:04

5.Do S4 with guest agent, could excute successfully and get expect error while re-excute it while it finish the first time
# virsh dompmsuspend 7.0 --target disk
Domain 7.0 successfully suspended


# virsh dompmsuspend 7.0 --target disk
error: Domain 7.0 could not be suspended
error: Requested operation is not valid: domain is not running

According to the upper steps, mark this bug verified

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html