Bug 1823309

Summary: timeout for agent guest-sync should be the same with user-specified timeout if it was below than 5s
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Lili Zhu <lizhu>
Component: libvirtAssignee: Jonathon Jongsma <jjongsma>
Status: CLOSED ERRATA QA Contact: Lili Zhu <lizhu>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.2CC: chhu, jdenemar, jsuchane, lmen, virt-maint, xuzhang
Target Milestone: rcKeywords: Triaged
Target Release: 8.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-6.3.0-1.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-17 17:48:08 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:

Description Lili Zhu 2020-04-13 08:42:24 UTC
Description of problem:
timeout for agent guest-sync should be the same with user-specified timeout if it was below than 5s

Version-Release number of selected component (if applicable):
libvirt-devel-6.0.0-17.module+el8.2.0+6257+0d066c28.x86_64
qemu-guest-agent-4.2.0-17.module+el8.2.0+6141+0f540f16.x86_64

How reproducible:
100%

Steps to Reproduce:
1. login into the guest, set breakpoint on qemu_guest_sync
# virsh console avocado-vt-vm1
Connected to domain avocado-vt-vm1
Escape character is ^]

[root@localhost ~]# gdb -p `pidof qemu-ga`
(gdb) br qmp_guest_sync
Breakpoint 1 at 0x5634f800c790
(gdb) c
Continuing.

2. set the agent time to 1s
# virsh guest-agent-timeout avocado-vt-vm1 --timeout 1

3. try to get filesystem of guest, will hit the breakpoint set above
# date; virsh domfsinfo avocado-vt-vm1 ; date
Mon Apr 13 04:39:36 EDT 2020
error: Unable to get filesystem information
error: Guest agent is not responding: Guest agent not available for now

Mon Apr 13 04:39:41 EDT 2020


Actual results:
when set agent timeout short than 5s, the actual timeout for guest-sync is still 5s




Additional info:

Comment 1 Lili Zhu 2020-04-13 08:45:16 UTC
upstream patch:

commit d9605abed68af4b65c4e04386346a2fd372d7ab9
Author: Jonathon Jongsma <jjongsma>
Date:   Fri Mar 20 17:28:10 2020 -0500

    qemu: fix response timeout for agent guest-sync

Comment 5 Lili Zhu 2020-08-03 10:00:42 UTC
Verify this bug with:
libvirt-6.5.0-1.module+el8.3.0+7323+d54bb644.x86_64
qemu-guest-agent-5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64

Verification steps:
1. login into the guest, set breakpoint on qemu_guest_sync
# virsh console rhel8.3
Connected to domain rhel8.3
Escape character is ^]

[root@localhost ~]# gdb -p `pidof qemu-ga`
(gdb) br qmp_guest_sync
Breakpoint 1 at 0x55d39676ea90: file /usr/src/debug/qemu-kvm-5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64/qga/commands.c, line 56.
(gdb) c
Continuing.

2. set the agent time to 1s
# virsh guest-agent-timeout rhel8.3 --timeout 1

3. try to get filesystem of guest, will hit the breakpoint set above
# date; virsh domfsinfo rhel8.3 ; date
Mon Aug  3 05:52:53 EDT 2020
error: Unable to get filesystem information
error: Guest agent is not responding: Guest agent not available for now

Mon Aug  3 05:52:54 EDT 2020

The timeout here is 1s


4. set the agent time to 10s
# virsh guest-agent-timeout rhel8.3 --timeout 10

5. try to get filesystem of guest, will hit the breakpoint set above
# date; virsh domfsinfo rhel8.3 ; date
Mon Aug  3 05:58:37 EDT 2020
error: Unable to get filesystem information
error: Guest agent is not responding: Guest agent not available for now

Mon Aug  3 05:58:42 EDT 2020
The timeout here is 5s

As the testing result matches with the expected result, mark the bug as verified

Comment 8 errata-xmlrpc 2020-11-17 17:48:08 UTC
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 (virt:8.3 bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2020:5137