Bug 1436976

(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.

(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.

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

(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.

For windows, "The frozen state is limited for up to 10 seconds by VSS". I'll propose a patch for the qga QMP documentation.

proposed doc improvement:
http://patchew.org/QEMU/20170403095438.15423-1-marcandre.lureau@redhat.com/

(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).

(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?

(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.

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?

(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.

doc issue for now, moving to 7.5

In release 2.10
Doc commit 1dbfbc17fe783e34644daf4abbb8f4e17344abcd

qemu-ga didn't get rebase this release, no rush to backport doc improvements, moving to 7.6

fixed upstream in commit 1dbfbc17fe783e34644daf4abbb8f4e17344abcd

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.

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.