RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1436976 - After executing with a non-existing mountpoint, 'virsh domfsfreeze' can not work again
Summary: After executing with a non-existing mountpoint, 'virsh domfsfreeze' can not w...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-guest-agent
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Marc-Andre Lureau
QA Contact: FuXiangChun
URL:
Whiteboard:
Depends On:
Blocks: 1473046
TreeView+ depends on / blocked
 
Reported: 2017-03-29 07:30 UTC by yafu
Modified: 2018-08-08 09:50 UTC (History)
9 users (show)

Fixed In Version: qemu-guest-agent-2.12.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-08 09:50:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description yafu 2017-03-29 07:30:43 UTC
Description of problem:
After executing with a non-existing mountpoint, 'virsh domfsfreeze' can not work again.

Version-Release number of selected component (if applicable):
libvirt-3.1.0-2.el7.x86_64
qemu-kvm-rhev-2.8.0-6.el7.x86_64
qemu-guest-agent-2.8.0-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Set mountpoint as a non-existing mountpoing
#virsh domfsfreeze rhel7.3-min test
Froze 0 filesystem(s)

2.Check the guest os, the os can still work correctly;

3.# virsh domfsfreeze rhel7.3-min
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

Actual results:
Step3 failed even no fs freeze in step1

Expected results:
Step3 should execute correctly since no fs freeze in step1

Comment 2 Marc-Andre Lureau 2017-03-29 14:31:25 UTC
(In reply to yafu from comment #0)
> Actual results:
> Step3 failed even no fs freeze in step1
> 
> Expected results:
> Step3 should execute correctly since no fs freeze in step1

It's not considered an error to pass an invalid mount point. So even if no mountpoints got frozen, it's still a partial froze, and you need to thaw it to reenable freeze and other commands.

Is there a problem with this behaviour?

I think we should consider this notabug otherwise.

Comment 3 yafu 2017-03-30 03:09:35 UTC
(In reply to Marc-Andre Lureau from comment #2)
> (In reply to yafu from comment #0)
> > Actual results:
> > Step3 failed even no fs freeze in step1
> > 
> > Expected results:
> > Step3 should execute correctly since no fs freeze in step1
> 
> It's not considered an error to pass an invalid mount point. So even if no
> mountpoints got frozen, it's still a partial froze, and you need to thaw it
> to reenable freeze and other commands.
> 
> Is there a problem with this behaviour?
> 
> I think we should consider this notabug otherwise.

I think the behaviour it's confused. For the invalid mount point, even it's not considered an error to pass, but it's still strange to be a partial froze.  Maybe we can add description for the behaviour in the document if not considered to change the behaviour.

Comment 4 yafu 2017-03-31 09:49:25 UTC
Hi,Marc,

I also test the 'virsh domfsfreeze' with windows os and found it does not work with windows even it does not report error.  The windows os can be used normally after executing 'virsh domfsfreeze'. I am not sure whether this command supported in the windows os. If not support, maybe it's better to report errors like other unsupported cmds.  such as:
# virsh domifaddr win2012 --source agent
error: Failed to query for interfaces addresses
error: internal error: unable to execute QEMU agent command 'guest-network-get-interfaces': this feature or command is not currently supported

Comment 5 Marc-Andre Lureau 2017-04-03 09:34:08 UTC
(In reply to yafu from comment #4)
> Hi,Marc,
> 
> I also test the 'virsh domfsfreeze' with windows os and found it does not
> work with windows even it does not report error.  The windows os can be used
> normally after executing 'virsh domfsfreeze'. I am not sure whether this
> command supported in the windows os. If not support, maybe it's better to
> report errors like other unsupported cmds.  such as:
> # virsh domifaddr win2012 --source agent
> error: Failed to query for interfaces addresses
> error: internal error: unable to execute QEMU agent command
> 'guest-network-get-interfaces': this feature or command is not currently
> supported

fsfreeze is implemented on windows.

You need the VSS provider library for it to work. If it's not loaded it returns an unsupported error.

Comment 6 Marc-Andre Lureau 2017-04-03 09:36:16 UTC
For windows, "The frozen state is limited for up to 10 seconds by VSS". I'll propose a patch for the qga QMP documentation.

Comment 7 Marc-Andre Lureau 2017-04-03 09:58:21 UTC
proposed doc improvement:
http://patchew.org/QEMU/20170403095438.15423-1-marcandre.lureau@redhat.com/

Comment 8 Ademar Reis 2017-04-03 13:04:48 UTC
(In reply to Marc-Andre Lureau from comment #7)
> proposed doc improvement:
> http://patchew.org/QEMU/20170403095438.15423-1-marcandre.lureau@redhat.com/

But the proposal is for upstream, so reverting the BZ back to NEW (should be changed to POST if merged in 2.9, or if backported to downstream).

Comment 9 Marc-Andre Lureau 2017-04-03 13:07:22 UTC
(In reply to Ademar Reis from comment #8)
> (In reply to Marc-Andre Lureau from comment #7)
> > proposed doc improvement:
> > http://patchew.org/QEMU/20170403095438.15423-1-marcandre.lureau@redhat.com/
> 
> But the proposal is for upstream, so reverting the BZ back to NEW (should be
> changed to POST if merged in 2.9, or if backported to downstream).

yafu, can we close this bug since it is now clarified?

Comment 10 yafu 2017-04-05 02:45:30 UTC
(In reply to Marc-Andre Lureau from comment #9)
> (In reply to Ademar Reis from comment #8)
> > (In reply to Marc-Andre Lureau from comment #7)
> > > proposed doc improvement:
> > > http://patchew.org/QEMU/20170403095438.15423-1-marcandre.lureau@redhat.com/
> > 
> > But the proposal is for upstream, so reverting the BZ back to NEW (should be
> > changed to POST if merged in 2.9, or if backported to downstream).
> 
> yafu, can we close this bug since it is now clarified?

As comment 8 said, I also think the bug's state should be changed to POST if merged in 2.9 or if backported to downstream.

Comment 11 Ademar Reis 2017-04-07 14:03:35 UTC
Marc-André, I see your change to the qemu-ga documentation upstream about the other aspect of this BZ, which is the failure on windows if VSS is not enabled.

But what about the initial problem reported, which was considered confusing even after you explained what was going on? See Comment #3:


(In reply to yafu from comment #3)
> (In reply to Marc-Andre Lureau from comment #2)
> > (In reply to yafu from comment #0)
> > > Actual results:
> > > Step3 failed even no fs freeze in step1
> > > 
> > > Expected results:
> > > Step3 should execute correctly since no fs freeze in step1
> > 
> > It's not considered an error to pass an invalid mount point. So even if no
> > mountpoints got frozen, it's still a partial froze, and you need to thaw it
> > to reenable freeze and other commands.
> > 
> > Is there a problem with this behaviour?
> > 
> > I think we should consider this notabug otherwise.
> 
> I think the behaviour it's confused. For the invalid mount point, even it's
> not considered an error to pass, but it's still strange to be a partial
> froze.  Maybe we can add description for the behaviour in the document if
> not considered to change the behaviour.

Any plans of changing this behavior or improving the documentation?

Comment 12 Marc-Andre Lureau 2017-04-07 15:27:00 UTC
(In reply to Ademar Reis from comment #11)
> Marc-André, I see your change to the qemu-ga documentation upstream about
> the other aspect of this BZ, which is the failure on windows if VSS is not
> enabled.
> 
> But what about the initial problem reported, which was considered confusing
> even after you explained what was going on? See Comment #3:
> 
> 
> (In reply to yafu from comment #3)
> > (In reply to Marc-Andre Lureau from comment #2)
> > > (In reply to yafu from comment #0)
> > > > Actual results:
> > > > Step3 failed even no fs freeze in step1
> > > > 
> > > > Expected results:
> > > > Step3 should execute correctly since no fs freeze in step1
> > > 
> > > It's not considered an error to pass an invalid mount point. So even if no
> > > mountpoints got frozen, it's still a partial froze, and you need to thaw it
> > > to reenable freeze and other commands.
> > > 
> > > Is there a problem with this behaviour?
> > > 
> > > I think we should consider this notabug otherwise.
> > 
> > I think the behaviour it's confused. For the invalid mount point, even it's
> > not considered an error to pass, but it's still strange to be a partial
> > froze.  Maybe we can add description for the behaviour in the document if
> > not considered to change the behaviour.
> 
> Any plans of changing this behavior or improving the documentation?

I added "Invalid mount points are ignored." to the doc.

So the doc reads: if freeze is succesful (did not return error), you may call thaw, and invalid mountpoints are ignored.

I think that's fine. Alternatively, we could change the API to return an error if all given mountpoints are invalid. But I don't think that changes much the usage. Or we may want to change the API to *not* ignore invalid mountpoints and return an error instead.

Comment 13 Marc-Andre Lureau 2017-04-12 11:33:07 UTC
doc issue for now, moving to 7.5

Comment 14 Marc-Andre Lureau 2017-10-06 11:28:50 UTC
In release 2.10
Doc commit 1dbfbc17fe783e34644daf4abbb8f4e17344abcd

Comment 15 Marc-Andre Lureau 2017-11-16 11:29:27 UTC
qemu-ga didn't get rebase this release, no rush to backport doc improvements, moving to 7.6

Comment 16 Marc-Andre Lureau 2018-04-16 13:18:43 UTC
fixed upstream in commit 1dbfbc17fe783e34644daf4abbb8f4e17344abcd

Comment 18 FuXiangChun 2018-08-02 08:02:23 UTC
Marc-André,

QE tried to verify this bug with qemu-guest-agent-2.12.0-2.el7. Because only add description to doc and haven't code change. QE tested result is also the same before bz is fixed. But don't know how to check document changes from downstream package(qemu-guest-agent-2.12.0-2.el7). 

QE can find this change in qemu-2.12.0/qga/qapi-schema.json from source code file(qemu-guest-agent-2.12.0-2.el7.src.rpm).  Anyway. Could you tell QE how to find document changes from downstream package(qemu-guest-agent-2.12.0-2.el7). Thanks.

Comment 19 Marc-Andre Lureau 2018-08-02 10:38:16 UTC
qemu-guest-agent doesn't ship qemu guest-agent protocol documentation.

I am not sure it should, anyway you use libvirt commands to do the operation.

I suggest we move & close the bug upstream.


Note You need to log in before you can comment on or make changes to this bug.