Created attachment 1163016 [details]
libvirtd log when guest resumes successfully

Can you please re-test this with current libvirt build? Should be already fixed.
Thanks.

*** This bug has been marked as a duplicate of bug 1265902 ***

Heh, I didn't really want to close this as a duplicate; bug 1265902 is related since the reason is the same, but the path is a bit different and was fixed later...

This bug is already fixed upstream by v1.2.21-90-g2c4ba8b:

commit 2c4ba8b4f3d20c0cb14e8ee91f087d98a0406802
Author:     Jiri Denemark <jdenemar>
AuthorDate: Wed Nov 11 18:02:23 2015 +0100
Commit:     Jiri Denemark <jdenemar>
CommitDate: Thu Nov 19 09:41:23 2015 +0100

    qemu: Use -incoming defer for migrations
    
    Traditionally, we pass incoming migration URI on QEMU command line,
    which has some drawbacks. Depending on the URI QEMU may initialize its
    migration state immediately without giving us a chance to set any
    additional migration parameters (this applies mainly for fd: URIs). For
    some URIs the monitor may be completely blocked from the beginning until
    migration is finished, which means we may be stuck in qmp_capabilities
    command without being able to send any QMP commands.
    
    QEMU solved this by introducing "defer" parameter for -incoming command
    line option. This will tell QEMU to prepare for an incoming migration
    while the actual incoming URI is sent using migrate-incoming QMP
    command. Before calling this command we can normally talk to the
    monitor and even set any migration parameters which will be honored by
    the incoming migration.
    
    Signed-off-by: Jiri Denemark <jdenemar>

Reproduce this bug  with libvirt-1.2.17-13.el7_2.5
Steps to reproduce:

1.create an empty file to save ping messages.
#echo > unreach.txt

2.Use a loop command to do “managedsave--> start-->ping guest”.
#for((i=0;i<50;i++));do  (echo $i >> unreach.txt; virsh managedsave testvm; virsh start testvm; (ping 192.168.122.46 >> unreach.txt &); sleep 4; kill `pgrep ping`); done

3.Check unreach.txt to find whether there is unreachable result:
# cat unreach.txt|grep Unreachable
From 192.168.122.1 icmp_seq=1 Destination Host Unreachable
From 192.168.122.1 icmp_seq=2 Destination Host Unreachable
From 192.168.122.1 icmp_seq=3 Destination Host Unreachable
From 192.168.122.1 icmp_seq=4 Destination Host Unreachable
From 192.168.122.1 icmp_seq=1 Destination Host Unreachable
From 192.168.122.1 icmp_seq=2 Destination Host Unreachable
From 192.168.122.1 icmp_seq=3 Destination Host Unreachable
From 192.168.122.1 icmp_seq=4 Destination Host Unreachable
From 192.168.122.1 icmp_seq=1 Destination Host Unreachable
......

-------------------
Verify this bug with libvirt-2.0.0-1.el7.x86_64
Steps to verify:

1.#echo > unreach.txt

2.#for((i=0;i<50;i++));do  (echo $i >> unreach.txt; virsh managedsave testvm; virsh start testvm; (ping 192.168.122.207 >> unreach.txt &); sleep 4; kill `pgrep ping`); done

3.Check unreach.txt, no unreachable results:
# cat unreach.txt|grep Unreachable
(nothing output)

Since the result is as expected, 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/RHSA-2016-2577.html