Bug 1928806

Summary: Improve error message when 'guest-fsfreeze-freeze' is issued twice
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Peter Krempa <pkrempa>
Component: qemu-kvmAssignee: Marc-Andre Lureau <marcandre.lureau>
qemu-kvm sub component: Guest Agent QA Contact: dehanmeng <demeng>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: medium CC: ddepaula, demeng, jferlan, jinzhao, marcandre.lureau, virt-maint
Version: 8.2Keywords: RFE, Triaged
Target Milestone: rc   
Target Release: 8.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-6.0.0-16.module+el8.5.0+10848+2dccc46d Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1972052 (view as bug list) Environment:
Last Closed: 2021-11-16 07:51:42 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: 1972052    

Description Peter Krempa 2021-02-15 15:29:39 UTC
Description of problem:
Trying to freeze the filesystems when they are already frozen produces an error message which doesn't clearly state that the filesystems are already frozen:

{"error": {"class": "CommandNotFound", "desc": "The command guest-fsfreeze-freeze has been disabled for this instance"}}

The error message can be confused with guest-fsfreeze-freeze being disabled.

Version-Release number of selected component (if applicable):
any recent versions

How reproducible:
always

Steps to Reproduce:

reproducer via libvirt:

$ virsh domfsfreeze VMNAME
Froze 2 filesystem(s)

$ virsh domfsfreeze VMNAME
error: Unable to freeze filesystems
error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': The command guest-fsfreeze-freeze has been disabled for this instance

$ virsh domfsthaw VMNAME
Thawed 2 filesystem(s)

$ virsh domfsthaw VMNAME
Thawed 0 filesystem(s)

$ virsh domfsfreeze VMNAME
Froze 2 filesystem(s)

Note that those are almost direct wrappers for 'guest-fsfreeze-freeze' and 'guest-fsfreeze-thaw'.

Actual results:


Expected results:


Additional info:

Comment 1 Marc-Andre Lureau 2021-02-16 13:25:17 UTC
> {"error": {"class": "CommandNotFound", "desc": "The command guest-fsfreeze-freeze has been disabled for this instance"}}
> The error message can be confused with guest-fsfreeze-freeze being disabled.

It is disabled though. what error message do you suggest? 


{"error": {"class": "CommandNotFound", "desc": "The command guest-fsfreeze-freeze has been disabled after freeze for this instance"}} ?

Comment 2 Peter Krempa 2021-03-16 13:58:06 UTC
Sorry I've missed the needinfo. I'm okay with the version from the patch posted upstream https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06099.html

Comment 3 Marc-Andre Lureau 2021-03-16 14:43:22 UTC
Can you review-by on the ML? I am afraid it is going to miss the deadline though, but perhaps mergeable during soft-freeze period.

Comment 4 Peter Krempa 2021-03-17 12:41:12 UTC
Done, hopefully minor error message changes are allowed.

Comment 5 Peter Krempa 2021-03-18 14:27:10 UTC
The commit was pushed upstream:

commit c98939daeca3beb21c85560acede8d3529e363d9
Author: Marc-André Lureau <marcandre.lureau>
Date:   Fri Feb 19 12:28:14 2021 +0400

    qga: return a more explicit error on why a command is disabled
    
    qmp_disable_command() now takes an optional error string to return a
    more explicit error message.
    
v5.2.0-2981-gc98939daec

Comment 6 Marc-Andre Lureau 2021-03-18 14:43:10 UTC
Not sure we want to backport that, I would vote for closing->UPSTREAM and wait for next update.

Peter, what do you think?

Comment 9 dehanmeng 2021-04-27 06:11:03 UTC
The ITM10 is coming soon and this bz's status still is POST, May I ask for the situation? or we'd better change ITM for it? 

Thanks
Dehan Meng

Comment 11 John Ferlan 2021-04-27 16:07:37 UTC
(In reply to dehanmeng from comment #9)
> The ITM10 is coming soon and this bz's status still is POST, May I ask for
> the situation? or we'd better change ITM for it? 
> 
> Thanks
> Dehan Meng

I've moved it to 14 - feel free to change it. I set ITM before DTM was available in order to get release+ (and not have to think about it again). 

At this point we are still waiting on (the final) upstream qemu-6.0 to be rebased downstream - a last minute bug found in upstream would definitely affect downstream testing that does hotplug of network devices, so it's better to just get the final bits than have to clean up the resulting failures...

FWIW: We talked about the general setting of ITM's for all bz's last week at the RHEL-AV synch meeting - there may be a mass update coming soon to match the 14 I used here.

Comment 15 dehanmeng 2021-05-13 05:45:28 UTC
reproduce this issue:
steps as comment0
Version: qemu-guest-agent-5.2.0-15.module+el8.4.0+10650

Actual result:
{"execute":"guest-fsfreeze-freeze"}
{"return": 2}
{"execute":"guest-fsfreeze-freeze"}
{"error": {"class": "CommandNotFound", "desc": "The command guest-fsfreeze-freeze has been disabled for this instance"}}

Verify this issue:
steps as above:
Version: qemu-kvm-6.0.0-16.module+el8.5.0+10848+2dccc46d

Actual result:
{"execute":"guest-fsfreeze-freeze"}
{"return": 2}
{"execute":"guest-fsfreeze-freeze"}
{"error": {"class": "CommandNotFound", "desc": "Command guest-fsfreeze-freeze has been disabled: the agent is in frozen state"}}

Comment 16 dehanmeng 2021-06-24 01:47:28 UTC
This bug still exists on RHEL850-virt, so do we have a plan to fix it on RHEL-virt?

Comment 17 Marc-Andre Lureau 2021-06-24 12:43:39 UTC
(In reply to dehanmeng from comment #16)
> This bug still exists on RHEL850-virt, so do we have a plan to fix it on
> RHEL-virt?

It was treated as an enhancement. You'd have to make a good case to consider it a bug and the "fix" be backported. Ie, in which ways does the error report change help you to fix a problem?

Comment 18 dehanmeng 2021-06-25 02:51:11 UTC
(In reply to Marc-Andre Lureau from comment #17)
> (In reply to dehanmeng from comment #16)
> > This bug still exists on RHEL850-virt, so do we have a plan to fix it on
> > RHEL-virt?
> 
> It was treated as an enhancement. You'd have to make a good case to consider
> it a bug and the "fix" be backported. Ie, in which ways does the error
> report change help you to fix a problem?

Thanks Marc, you're right, after discussion, this issue don't affect our product level and just wait for rebase it's totally okay. thanks again.

Comment 20 errata-xmlrpc 2021-11-16 07:51:42 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:av 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-2021:4684