Bug 2041665

Summary:	guestinfo returns wrong value when domain's filesystems are frozen
Product:	Red Hat Enterprise Linux 9	Reporter:	Lili Zhu <lizhu>
Component:	libvirt	Assignee:	Peter Krempa <pkrempa>
libvirt sub component:	General	QA Contact:	Lili Zhu <lizhu>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	fjin, jdenemar, jtomko, lmen, pkrempa, virt-maint, xuzhang
Version:	9.0	Keywords:	Triaged
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libvirt-8.1.0-1.el9	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-11-15 10:03:03 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:	8.1.0
Embargoed:

Description Lili Zhu 2022-01-18 02:57:33 UTC

Description of problem:
guestinfo returns wrong value when domain's filesystems are frozen

Version-Release number of selected component (if applicable):
libvirt-8.0.0-1.el9.x86_64

How reproducible:
qemu-kvm-6.2.0-3.el9.x86_64

Steps to Reproduce:
1. prepare a guest with working guest agent
# virsh domtime avocado-vt-vm1 
Time: 1642473747

2. freeze guest's fileystem
# virsh domfsfreeze avocado-vt-vm1 
Froze 2 filesystem(s)

3. check guest info
# virsh guestinfo avocado-vt-vm1 
(no output)

4. check the return value of last command
# echo $?
0

Expected results:
Exit status of the cmd line step 3 should be non-zero, and report a error like:
unable to execute QEMU agent command: the agent is in frozen state

Additional info:
1. Invoking the specified APIs of guestinfo, all would return correctly
# virsh guestinfo avocado-vt-vm1 --os
error: internal error: unable to execute QEMU agent command 'guest-get-osinfo': Command guest-get-osinfo has been disabled: the agent is in frozen state

2. Invoking other guest agent APIs, all would return correctly
# virsh shutdown avocado-vt-vm1 --mode agent 
error: Failed to shutdown domain 'avocado-vt-vm1'
error: internal error: unable to execute QEMU agent command 'guest-shutdown': Command guest-shutdown has been disabled: the agent is in frozen state

Comment 1 Peter Krempa 2022-01-18 08:34:53 UTC

Note that the described behaviour is deliberate and (somewhat vaguely) documented in 'man virsh'

"When run without any arguments, this command prints all information types that are supported by the guest agent. You can limit the types of information that are  returned  by specifying  one or more flags.  If a requested information type is not supported, the processes will provide an exit code of 1.  Available information types flags are --user, --os, --timezone, --hostname, --filesystem, --disk and --interface."

The idea is that if you don't select any specific group of information, the command prints everything that it could get, which in this case is nothing.

If you think the documentation is unclear we can clarify that, but the code is deliberately and expectedly returning success.

Comment 2 Lili Zhu 2022-01-19 08:30:22 UTC

Hi, Peter

(In reply to Peter Krempa from comment #1)
> Note that the described behaviour is deliberate and (somewhat vaguely)
> documented in 'man virsh'
> 
> "When run without any arguments, this command prints all information types
> that are supported by the guest agent. You can limit the types of
> information that are  returned  by specifying  one or more flags.  If a
> requested information type is not supported, the processes will provide an
> exit code of 1.  Available information types flags are --user, --os,
> --timezone, --hostname, --filesystem, --disk and --interface."
> 
> The idea is that if you don't select any specific group of information, the
> command prints everything that it could get, which in this case is nothing.
> 
I think the documentation is vague. I thought the documentation above talks about the
The information types guestinfo supports. If you do not point out, I would not think about
the circumstances when guestinfo can not get info(Here, the info is not some kind of unsupported info).

> If you think the documentation is unclear we can clarify that, but the code
> is deliberately and expectedly returning success.
Yes, please. Thanks.

Comment 3 Peter Krempa 2022-01-19 18:05:18 UTC

Fixed upstream:

commit 755b16d10a90617b57dbaf900abe3ccadbe45324
Author: Peter Krempa <pkrempa>
Date:   Wed Jan 19 09:49:31 2022 +0100

    docs: man: virsh: Document more carefully that 'guestinfo' can return nothing
    
    When invoking 'virsh guestinfo $VM' without explicitly specifying a
    group of information to return, virsh always reports success even when
    the guest agent doesn't report any information in the current state.
    This is desired in situations when you are okay with stats being missing
    and avoids spurious errors being reported.
    
    Clarify that this is really desired in the man page.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2041665
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Andrea Bolognani <abologna>
    Signed-off-by: Peter Krempa <pkrempa>

v8.0.0-118-g755b16d10a

Comment 4 Lili Zhu 2022-03-19 14:50:06 UTC

Tested with:
libvirt-8.2.0-1.fc35.x86_64

Check the doc

# man virsh
...
 When run without any arguments, this command prints all information types that are supported by the guest agent at that point, omitting unavailable ones.  Success  is always reported in this case.

Comment 7 Lili Zhu 2022-04-29 04:03:01 UTC

Verified this bug with:
libvirt-8.2.0-1.el9.x86_64

The testing steps are the same with Comment #4.

The testing result matches with the expected result, mark the bug as verified.

Comment 9 errata-xmlrpc 2022-11-15 10:03:03 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 (Low: libvirt security, 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/RHSA-2022:8003