Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1470468

Summary: [virtio-win][qemu-ga-win][upstream] if guest is auto-released after 10s, the following "guest-fsfreeze-freeze" and "guest-fsfreeze-thaw" should not prompt error.
Product: Red Hat Enterprise Linux 7 Reporter: xiagao
Component: virtio-winAssignee: Sameeh Jubran <sjubran>
virtio-win sub component: qemu-ga-win QA Contact: Virtualization Bugs <virt-bugs>
Status: CLOSED NOTABUG Docs Contact:
Severity: low    
Priority: medium CC: ailan, lijin, lmiksik, michen, phou, sjubran, virt-bugs, wyu, xiagao, yvugenfi
Version: 7.4   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1406271 Environment:
Last Closed: 2017-08-16 09:48:11 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: 1406271    
Bug Blocks: 1473046    

Comment 2 Sameeh Jubran 2017-07-23 13:24:10 UTC 
I have already sent a patch upstream which attempts to fix the issue but the patch was rejected. Either way now I don't believe that we should change this behaviour as the implementation of the Freeze command is limited to 10 seconds due to limitations from Windows, I think that in case that more than 10 seconds has passed since execution of the Freeze command a suitable message should be displayed. The message informs the user that the freeze operation was only to a period of 10 seconds and that the freeze command have passed this time slice of 10 seconds.

This approach gives the user the information needed to decide what needs to do as the freeze/thaw commands usually executed in order to backup the disks of the guest, if the freeze wasn't held, the backed up data may not be accurate and therefore the user should be informed.
Comment 3 Sameeh Jubran 2017-08-13 16:17:42 UTC 
Can you please reply to my comment above? can we close this?
Comment 4 xiagao 2017-08-14 00:08:35 UTC 
(In reply to Sameeh Jubran from comment #2)
> I have already sent a patch upstream which attempts to fix the issue but the
> patch was rejected. Either way now I don't believe that we should change
> this behaviour as the implementation of the Freeze command is limited to 10
> seconds due to limitations from Windows, I think that in case that more than
> 10 seconds has passed since execution of the Freeze command a suitable
> message should be displayed. The message informs the user that the freeze
> operation was only to a period of 10 seconds and that the freeze command
> have passed this time slice of 10 seconds.
> 
> This approach gives the user the information needed to decide what needs to
> do as the freeze/thaw commands usually executed in order to backup the disks
> of the guest, if the freeze wasn't held, the backed up data may not be
> accurate and therefore the user should be informed.

I think it's better to prompt a suitable message to inform user that file systems are released after 10s.

1)Freeze guest filesystem.
   {"execute":"guest-fsfreeze-freeze"}
   {"return": 2}
   {"execute":"guest-fsfreeze-status"}        
   {"return": "frozen"}

2)after >10s, thaw guest
   {"execute":"guest-fsfreeze-thaw"}
   {"error": {"desc": "couldn't hold writes: fsfreeze is limited up to 10 seconds:  (error: 8004230f)"}}   -----> I think this error info is not friendly, could you modify it with a suitable message ?

Thanks.
Comment 5 Sameeh Jubran 2017-08-14 07:20:49 UTC 
(In reply to xiagao from comment #4)
> (In reply to Sameeh Jubran from comment #2)
> > I have already sent a patch upstream which attempts to fix the issue but the
> > patch was rejected. Either way now I don't believe that we should change
> > this behaviour as the implementation of the Freeze command is limited to 10
> > seconds due to limitations from Windows, I think that in case that more than
> > 10 seconds has passed since execution of the Freeze command a suitable
> > message should be displayed. The message informs the user that the freeze
> > operation was only to a period of 10 seconds and that the freeze command
> > have passed this time slice of 10 seconds.
> > 
> > This approach gives the user the information needed to decide what needs to
> > do as the freeze/thaw commands usually executed in order to backup the disks
> > of the guest, if the freeze wasn't held, the backed up data may not be
> > accurate and therefore the user should be informed.
> 
> I think it's better to prompt a suitable message to inform user that file
> systems are released after 10s.
> 
> 1)Freeze guest filesystem.
>    {"execute":"guest-fsfreeze-freeze"}
>    {"return": 2}
>    {"execute":"guest-fsfreeze-status"}        
>    {"return": "frozen"}
> 
> 2)after >10s, thaw guest
>    {"execute":"guest-fsfreeze-thaw"}
>    {"error": {"desc": "couldn't hold writes: fsfreeze is limited up to 10
> seconds:  (error: 8004230f)"}}   -----> I think this error info is not
> friendly, could you modify it with a suitable message ?
This is the message that is currently displayed in upstream and I want to keep this repository identical to upstream, so I really prefer not to change this at all unless it was changed on upstream.

Thanks :)
> 
> Thanks.
Comment 6 xiagao 2017-08-14 07:33:06 UTC 
(In reply to Sameeh Jubran from comment #5)
> (In reply to xiagao from comment #4)
> > (In reply to Sameeh Jubran from comment #2)
> > > I have already sent a patch upstream which attempts to fix the issue but the
> > > patch was rejected. Either way now I don't believe that we should change
> > > this behaviour as the implementation of the Freeze command is limited to 10
> > > seconds due to limitations from Windows, I think that in case that more than
> > > 10 seconds has passed since execution of the Freeze command a suitable
> > > message should be displayed. The message informs the user that the freeze
> > > operation was only to a period of 10 seconds and that the freeze command
> > > have passed this time slice of 10 seconds.
> > > 
> > > This approach gives the user the information needed to decide what needs to
> > > do as the freeze/thaw commands usually executed in order to backup the disks
> > > of the guest, if the freeze wasn't held, the backed up data may not be
> > > accurate and therefore the user should be informed.
> > 
> > I think it's better to prompt a suitable message to inform user that file
> > systems are released after 10s.
> > 
> > 1)Freeze guest filesystem.
> >    {"execute":"guest-fsfreeze-freeze"}
> >    {"return": 2}
> >    {"execute":"guest-fsfreeze-status"}        
> >    {"return": "frozen"}
> > 
> > 2)after >10s, thaw guest
> >    {"execute":"guest-fsfreeze-thaw"}
> >    {"error": {"desc": "couldn't hold writes: fsfreeze is limited up to 10
> > seconds:  (error: 8004230f)"}}   -----> I think this error info is not
> > friendly, could you modify it with a suitable message ?
> This is the message that is currently displayed in upstream and I want to
> keep this repository identical to upstream, so I really prefer not to change
> this at all unless it was changed on upstream.
> 
> Thanks :)
> > 
> > Thanks.


Get it, thanks for explaination. Further confirm with you, in comment 2 you mean you sent a patch upstream which is aboout *displaying a suitable message about this issue*, but it's rejecked, yes ?
Comment 7 Sameeh Jubran 2017-08-14 07:51:06 UTC 
(In reply to xiagao from comment #6)
> (In reply to Sameeh Jubran from comment #5)
> > (In reply to xiagao from comment #4)
> > > (In reply to Sameeh Jubran from comment #2)
> > > > I have already sent a patch upstream which attempts to fix the issue but the
> > > > patch was rejected. Either way now I don't believe that we should change
> > > > this behaviour as the implementation of the Freeze command is limited to 10
> > > > seconds due to limitations from Windows, I think that in case that more than
> > > > 10 seconds has passed since execution of the Freeze command a suitable
> > > > message should be displayed. The message informs the user that the freeze
> > > > operation was only to a period of 10 seconds and that the freeze command
> > > > have passed this time slice of 10 seconds.
> > > > 
> > > > This approach gives the user the information needed to decide what needs to
> > > > do as the freeze/thaw commands usually executed in order to backup the disks
> > > > of the guest, if the freeze wasn't held, the backed up data may not be
> > > > accurate and therefore the user should be informed.
> > > 
> > > I think it's better to prompt a suitable message to inform user that file
> > > systems are released after 10s.
> > > 
> > > 1)Freeze guest filesystem.
> > >    {"execute":"guest-fsfreeze-freeze"}
> > >    {"return": 2}
> > >    {"execute":"guest-fsfreeze-status"}        
> > >    {"return": "frozen"}
> > > 
> > > 2)after >10s, thaw guest
> > >    {"execute":"guest-fsfreeze-thaw"}
> > >    {"error": {"desc": "couldn't hold writes: fsfreeze is limited up to 10
> > > seconds:  (error: 8004230f)"}}   -----> I think this error info is not
> > > friendly, could you modify it with a suitable message ?
> > This is the message that is currently displayed in upstream and I want to
> > keep this repository identical to upstream, so I really prefer not to change
> > this at all unless it was changed on upstream.
> > 
> > Thanks :)
> > > 
> > > Thanks.
> 
> 
> Get it, thanks for explaination. Further confirm with you, in comment 2 you
> mean you sent a patch upstream which is aboout *displaying a suitable
> message about this issue*, but it's rejecked, yes ?
Not exactly, the patch that I have sent would eliminate the message at all, however I think I can try and send a patch upstream which attempts to make the message more user friendly, but I don't think that this BZ is severe at all or even that it is needed. Please refer to the following BZ, it discusses the same issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1021913
Comment 8 Sameeh Jubran 2017-08-16 09:48:11 UTC 
I am closing this issue.