Bug 1293351

Summary:	libvirt calls to qemu-guest-agent take 5 s just to report agent unavailability
Product:	[Community] Virtualization Tools	Reporter:	Milan Zamazal <mzamazal>
Component:	libvirt	Assignee:	Michal Privoznik <mprivozn>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	dyuan, fjin, mprivozn, rbalakri, zhwang
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-02-11 06:03:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1244567

Description Milan Zamazal 2015-12-21 14:10:24 UTC

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:

Comment 1 Michal Privoznik 2015-12-22 06:50:32 UTC

Patch proposed upstream:

https://www.redhat.com/archives/libvir-list/2015-December/msg00822.html

Comment 2 Michal Privoznik 2015-12-22 14:42:03 UTC

v2:

https://www.redhat.com/archives/libvir-list/2015-December/msg00839.html

Comment 3 Michal Privoznik 2016-01-11 10:31:52 UTC

v3:

https://www.redhat.com/archives/libvir-list/2016-January/msg00351.html

Comment 4 Michal Privoznik 2016-01-18 10:55:13 UTC

v4:

https://www.redhat.com/archives/libvir-list/2016-January/msg00733.html

Comment 5 Michal Privoznik 2016-02-03 13:39:20 UTC

v5:

https://www.redhat.com/archives/libvir-list/2016-February/msg00159.html

Comment 6 Michal Privoznik 2016-02-11 06:03:32 UTC

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