Red Hat Bugzilla – Bug 1244567
Guest agent should report proper error while guest agent was unreachable and restart libvirtd service
Last modified: 2016-11-03 14:19:59 EDT
Description of problem: Guest agent should report proper error while guest agent was unreachable and restart libvirtd service Version-Release number of selected component (if applicable): libvirt-1.2.17-1.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Start a guest with agent configured 2.stop the guest agent service inside the guest, then excute some commands depends on qemu-guest-agent, the command will report error right away. guest#systemctl stop qemu-guest-agent # time virsh domtime virt-tests-vm1 error: Guest agent is not responding: QEMU guest agent is not connected real 0m0.016s user 0m0.007s sys 0m0.005s 3.Restart the libvirtd service, found libvirt won't report the error right away, but still wait for the timeout of the command, this should be implemented #systemctl restart libvirtd # time virsh domtime virt-tests-vm1 error: Guest agent is not responding: Guest agent not available for now real 0m5.018s user 0m0.009s sys 0m0.002s Actual results: libvirt won't report the error right away, but still wait for the timeout of the command while guest agent was unreachable and restart libvirtd service Expected results: Guest agent should report proper error while guest agent was unreachable and restart libvirtd service Additional info:
Moving to POST: commit 88ed9d771e1e2ce26cfe1a3d0238ac5977f48208 Author: Michal Privoznik <mprivozn@redhat.com> AuthorDate: Fri Jan 8 17:03:48 2016 +0100 Commit: Michal Privoznik <mprivozn@redhat.com> CommitDate: Thu Feb 11 06:52:50 2016 +0100 qemu: Connect to guest agent iff needed https://bugzilla.redhat.com/show_bug.cgi?id=1293351 Since we already have virtio channel events, we know when guest agent within guest has (dis-)connected. Instead of us blindly connecting to a socket that no one is listening to, we can just follow what qemu-ga does. This has a nice benefit that we don't need to 'guest-ping' the agent just to timeout and find out nobody is listening. The way that this commit is implemented: - don't connect in qemuProcessLaunch directly, defer that to event callback (which already follows the agent) - processSerialChangedEvent - after migration is settled, before we resume vCPUs, ask qemu whether somebody is listening on the socket and if so, connect to it. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> v1.3.1-202-g88ed9d7
verified on libvirt-1.3.2-1.el7.x86_64, the results is expected. 1. Start a guest, the qemu-guest-agent will loaded and start automatically. 2. On the host, # time virsh domtime R7.2 Time: 1457062317 real 0m0.020s user 0m0.008s sys 0m0.007s 3. On the guest, stop the qemu-guest-agent # systemctl stop qemu-guest-agent 4. On the host, restart the libvirtd service. # systemctl restart libvirtd # time virsh domtime R7.2 error: Guest agent is not responding: QEMU guest agent is not connected real 0m0.020s user 0m0.008s sys 0m0.009s
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