Bug 1021913

(In reply to Qunfang Zhang from comment #0)

> 4. Freeze guest filesystem.
>    {"execute":"guest-fsfreeze-freeze"}
> 
> {"return": 1}
> 
> 
>  {"execute":"guest-fsfreeze-status"}
> {"return": "frozen"}
> 
> 5. Write some data inside guest, eg, download/copy some files.

I can think about two reasons that we might think it is a failure:

1. The write was done after 10 seconds were passed since the freeze command.
2. Windows kept the write request in-memory and didn't flush the data to the disk.
 
> 6. Thaw guest
>  {"execute":"guest-fsfreeze-thaw"}
> {"error": {"desc": "couldn't hold writes: fsfreeze is limited up to 10
> seconds:  (error: 8004230f)"}}
> 
> ==> Prompt error at the first time.

This error says that Windows auto-released the freeze after 10 seconds, so your request for a thaw is reduandent.
 
>    {"execute":"guest-fsfreeze-thaw"}
> {"return": 0}
> 
> ==> Succeed at the second time.

This is also a failure. The return value is the number of disks that were thawed.

Hi, Gal

I'm running the following script and then freeze guest. After a while (about 20~30s), open the "C:\\time.txt" file and found there's 9s (sometimes 10s) logs missing. 

......
Wed Oct 23 18:15:11 2013
Wed Oct 23 18:15:12 2013
Wed Oct 23 18:15:13 2013
Wed Oct 23 18:15:14 2013
Wed Oct 23 18:15:23 2013 <-- The time is not continuous here
Wed Oct 23 18:15:24 2013
Wed Oct 23 18:15:25 2013
Wed Oct 23 18:15:26 2013
Wed Oct 23 18:15:27 2013
.....


# cat test.py 
import time

result = open("C:\\time.txt", "w")

while 1:
    result.write("%s\n\r" % time.ctime())
    result.flush()
    time.sleep(1)


Gal,
(1) Does that mean the filesystem is frozen for about 10s and then auto-release as you said?   Have you find some clue about the problem and is it easy to fixed?
(2) Could I use this method to verify the VSS bug 948017 when this one gets fixed? 

Thanks,
Qunfang

(In reply to Qunfang Zhang from comment #4)
> Hi, Gal
> 
> I'm running the following script and then freeze guest. After a while (about
> 20~30s), open the "C:\\time.txt" file and found there's 9s (sometimes 10s)
> logs missing. 
> 
> ......
> Wed Oct 23 18:15:11 2013
> Wed Oct 23 18:15:12 2013
> Wed Oct 23 18:15:13 2013
> Wed Oct 23 18:15:14 2013
> Wed Oct 23 18:15:23 2013 <-- The time is not continuous here
> Wed Oct 23 18:15:24 2013
> Wed Oct 23 18:15:25 2013
> Wed Oct 23 18:15:26 2013
> Wed Oct 23 18:15:27 2013
> .....
> 
> 
> # cat test.py 
> import time
> 
> result = open("C:\\time.txt", "w")
> 
> while 1:
>     result.write("%s\n\r" % time.ctime())
>     result.flush()
>     time.sleep(1)
> 
> 
> Gal,
> (1) Does that mean the filesystem is frozen for about 10s and then
> auto-release as you said?   Have you find some clue about the problem and is
> it easy to fixed?

I believe that your script proves that the file system was freezed! Congratulation :-).

This is not a problem and will not be fixed. This is the documented behaviour of the VSS system. You only have a grace period of 10 seconds to backup your data without applications trying to write to the disk.

> (2) Could I use this method to verify the VSS bug 948017 when this one gets
> fixed? 

Yes, it looks like a good method to verify it.

> Thanks,
> Qunfang

Gal,

Thanks for the information. Cheers! And there's some other things we talked in this bz need to confirm with you:

(1) Even after 10 seconds passed after guest freezes, the "guest-fsfreeze-status" command will still return "frozen". This result is not suitable I think. Could we improve it to make sure it will not confuse user? As the system is auto-released the freeze after 10s.  

(2) Is the following error expected? 

{"error": {"desc": "couldn't hold writes: fsfreeze is limited up to 10 seconds:  (error: 8004230f)"}}

(3) And what does you mean about your last sentence in comment 3? Why this is a failure?  As the guest actually is auto-released the freeze, so it should return 0.

--------------------
>    {"execute":"guest-fsfreeze-thaw"}
> {"return": 0}
> 
> ==> Succeed at the second time.

This is also a failure. The return value is the number of disks that were thawed.
--------------------

Qunfang

Hi, guys

I remove the "Testblocker" keyword as it does not block us to use the virtagent function and the VSS feature after the discussion. But it is with bad user experience because after the guest auto-releases the freeze, the status is still "frozen" and prompts error if user thaw it via command. So, it's better to fix it in 6.5. Please correct me if I'm wrong.

Thanks,
Qunfang

As we said all of it is expected (other than the wrong return code). The default for the VSS final freeze is 10 seconds, and they do allow infinite time for preparations before the final freeze, so this should be enough.
The lost time ticks are probably due to the disk flush in the script, that has to wait (unlike the write itself).
So we have one bug with the return code, and it seems to be too late for 6.5, so I am OK with deferring it to 6.6 or a Z-stream. Lets wait a few more days.

Deferring to 6.6. Once this is cleared up we will decide whether to push in a Z-stream.

This behavior is by design and the json's schema file state it: "This (get guest fsfreeze state) may fail to properly report the current state as a result of some other guest processes having issued an fs freeze/thaw".

(In reply to Gal Hammer from comment #10)
> This behavior is by design and the json's schema file state it: "This (get
> guest fsfreeze state) may fail to properly report the current state as a
> result of some other guest processes having issued an fs freeze/thaw".

Yes, I found it now in the json's schema file. And do we have a plan to fix it in future release?  Thanks.

(In reply to Qunfang Zhang from comment #11)
> (In reply to Gal Hammer from comment #10)
> > This behavior is by design and the json's schema file state it: "This (get
> > guest fsfreeze state) may fail to properly report the current state as a
> > result of some other guest processes having issued an fs freeze/thaw".
> 
> Yes, I found it now in the json's schema file. And do we have a plan to fix
> it in future release?  Thanks.

I guess that's will be a management call, but I don't think we should try and fix it. Returning a status of a system that can be modified by more than one user is almost always unreliable.