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:
> {"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"}} ?
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
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.
Done, hopefully minor error message changes are allowed.
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
Not sure we want to backport that, I would vote for closing->UPSTREAM and wait for next update. Peter, what do you think?
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
(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.
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"}}
This bug still exists on RHEL850-virt, so do we have a plan to fix it on RHEL-virt?
(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?
(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.
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