Description of problem: When I call virDomainSetTime on a QEMU/kvm domain without qemu-guest-agent installed or running, it takes 5 seconds before the function returns error about the agent not being available. Version-Release number of selected component (if applicable): 1.2.17-13 CentOS 7 1.2.18.1-2 Fedora 23 How reproducible: Always reproducible. Steps to Reproduce: I can reproduce the bug in oVirt/VDSM environment (sorry, no simpler case around). 1. Use a VM running on a host with recent VDSM (4.0 snapshot), without qemu-guest-agent installed on the VM. 2. Enable debug logging in libvirtd. 3. Suspend the VM from oVirt Engine. 4. Run (awake) the VM from oVirt Engine. 5. In libvirtd.log, look for "qemuAgentGuestSync" and the corresponding time stamps. Actual results: It takes 5 seconds before the function returns an error about qemu-guest-agent not being available. Expected results: The function returns the error immediately. Additional info:
Patch proposed upstream: https://www.redhat.com/archives/libvir-list/2015-December/msg00822.html
v2: https://www.redhat.com/archives/libvir-list/2015-December/msg00839.html
v3: https://www.redhat.com/archives/libvir-list/2016-January/msg00351.html
v4: https://www.redhat.com/archives/libvir-list/2016-January/msg00733.html
v5: https://www.redhat.com/archives/libvir-list/2016-February/msg00159.html
I've just pushed patches upstream: commit 88ed9d771e1e2ce26cfe1a3d0238ac5977f48208 Author: Michal Privoznik <mprivozn> AuthorDate: Fri Jan 8 17:03:48 2016 +0100 Commit: Michal Privoznik <mprivozn> 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> v1.3.1-202-g88ed9d7