Bug 948017

Update: Hitachi is proposing it upstream. Please review the patch and help them get it merged:

http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg01963.html

(In reply to comment #1)
> Update: Hitachi is proposing it upstream. Please review the patch and help
> them get it merged:
> 
> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg01963.html

Hitachi is planning to post a v3 of the patch series in a couple of weeks. Please review it upstream so that we get this moving.

v3 of the patch series has been posted to qemu-devel. Please review it.

Confirmed with Ronen that the windows team will build and deliver the windows guest agent on the virtio-win channel. So we should remove guest-agent-win32 from our rpm package

Any progress in this bug?
I'm wondering because the status of this entry is still NEW.

Just wondering whether the component is correct? The bug is ON_QA but there's no content in "Fixed in Version" Field. The qemu-ga-win package does not in qemu-kvm build any more and it should move to virt-win build. Ademar, should we change the component?  And please correct me if I'm wrong. 

Thanks,
Qunfang

Hi, Gal

Is this method suitable to verify this bug? 

Action: Running the following script; freeze guest for a while (eg: 10s); thaw the guest; check the "C:\\time.txt" file.
Expected result: In the "C:\\time.txt", there should a peroid (10s in this case) log missing.

# 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)

Test this bug with win7-32 guest and win2012-64 guests with the following version:

Host:
kernel-2.6.32-425.el6.x86_64
qemu-kvm-0.12.1.2-2.414.el6.x86_64

Guest:
virtio-win-prewhql-72 (for virtio-serial driver)
qemu-ga-win-6.5-4 (guest agent)

Steps:

1. Boot up a guest:

 /usr/libexec/qemu-kvm -cpu SandyBridge -M rhel6.5.0 -enable-kvm -m 2G -smp 2,sockets=2,cores=1,threads=1 -name rhel6.4-64 -uuid 9a0e67ec-f286-d8e7-0548-0c1c9ec93009 -nodefconfig -nodefaults -monitor stdio -rtc base=utc,clock=host,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtserialport,bus=virtio-serial0.0,chardev=qga0,name=org.qemu.guest_agent.0 -drive file=/home/win2012-64-virtio.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:d5:51:8a,bus=pci.0,addr=0x3 -device usb-tablet,id=input0 -vnc :10 -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -qmp tcp:0:5555,server,nowait -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0

2. Install virtio-serial driver, qemu-ga-win msi, python2.7 inside guest.

3. Send some commands via guest agent. 
(On host)

# nc -U /tmp/qga.sock 

{"execute":"guest-ping"}
{"return": {}}

4. Run the following script inside guest:
# 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)

$test.py (run inside guest)

4. Freeze guest:

(1) Freeze 2~3s (<10s) and then thaw it with guest agent command.

{"execute":"guest-fsfreeze-freeze"}
{"return": 1}
{"execute":"guest-fsfreeze-thaw"}
{"return": 1}

Check "C:\time.txt" file inside guest:

Thu Oct 24 07:31:12 2013
Thu Oct 24 07:31:13 2013
Thu Oct 24 07:31:14 2013
Thu Oct 24 07:31:15 2013
Thu Oct 24 07:31:16 2013
Thu Oct 24 07:31:17 2013
Thu Oct 24 07:31:18 2013
Thu Oct 24 07:31:19 2013
Thu Oct 24 07:31:20 2013
Thu Oct 24 07:31:23 2013 <-- The time is not continuous from here
Thu Oct 24 07:31:24 2013
Thu Oct 24 07:31:25 2013
Thu Oct 24 07:31:26 2013



(2) Freeze for 1 min and then thaw it. (The guest auto-releases the freeze after 10s)


{"execute":"guest-fsfreeze-freeze"}
{"return": 1}
{"execute":"guest-fsfreeze-thaw"}
{"error": {"desc": "couldn't hold writes: fsfreeze is limited up to 10 seconds:  (error: 80042314)"}}
{"execute":"guest-fsfreeze-thaw"}
{"return": 0}


Thu Oct 24 06:39:51 2013
Thu Oct 24 06:39:52 2013
Thu Oct 24 06:39:53 2013
Thu Oct 24 06:39:54 2013
Thu Oct 24 06:39:55 2013
Thu Oct 24 06:39:56 2013
Thu Oct 24 06:39:57 2013
Thu Oct 24 06:40:08 2013 <-- The time is not continuous from here 
Thu Oct 24 06:40:09 2013
Thu Oct 24 06:40:10 2013
Thu Oct 24 06:40:11 2013
Thu Oct 24 06:40:12 2013
Thu Oct 24 06:40:13 2013
Thu Oct 24 06:40:14 2013
Thu Oct 24 06:40:15 2013 

Hi, Gal

Could you help check the above result? The script is frozen and can not continue writing data to disk (limited up to 10s) when guest receives the "fsfreeze" command. Is this the expected result to verify the bug?  There's 10s output missing in "C:\time.txt" file. But sometimes, I only see 9s log is missing.  Could we call this verified pass? 

Thanks,
Qunfang

Since we're out of time for the 6.5 qemu-kvm errata and we won't be able to push the code to qemu-kvm repository on time, I'm marking this bug as virtio-win (it'll be delivered in the supp channel and follows the same schedule as virtio-win)

I know this is not virtio-win, but for lack of the proper component, that's the best workaround I can think of.

Hello,
Thank you for testing this feature.

(In reply to Qunfang Zhang from comment #22)
> Could you help check the above result? The script is frozen and can not continue
> writing data to disk (limited up to 10s) when guest receives the
> "fsfreeze" command. Is this the expected result to verify the bug?  There's
> 10s output missing in "C:\time.txt" file. But sometimes, I only see 9s log
> is missing.  Could we call this verified pass? 

This is the expected result.
Windows operating system is limiting the freezing time up to 10 seconds to avoid
deadlocks. (Missing log can be for 9s based on timing of the write and of the
automatic thaw by Windows.)
When it is expired, the agent returns the error 80042314 on the fsfreeze-thaw,
as in your test result, so that libvirt can alert users that the snapshot can be
incomplete, and users should retry then, e.g. when the disk is more idle.

Regards,
Tomoki Sekiyama

Hello, Tomoki

Thank you for the confirmation and explanation. I will set this bug to VERIFIED. 

Hi, Vadim

Could you help add this bug to our rhel6.5 virito-win errata?  

Thanks,
Qunfang

The functionality is verified pass, however I will change the status back to ON_QA until it's confirmed that the virtio-win package is built and include it.

(In reply to Qunfang Zhang from comment #26)
> Hello, Tomoki
> 
> Thank you for the confirmation and explanation. I will set this bug to
> VERIFIED. 
> 
> Hi, Vadim
> 
> Could you help add this bug to our rhel6.5 virito-win errata?  

Hi Qunfang,
Tried get the following problem report:
1 error prohibited this update advisory form from being saved

There were problems with the following fields:

    Idsfixed Bug #948017 does not have the correct flags. Requires rhel-6.5.0,devel_ack,qa_ack,pm_ack but only has blocker?,devel_ack+,pm_ack?,qa_ack?,qe_test_coverage?,requires_doc_text+,rhel-6.5.0?.

> 
> Thanks,
> Qunfang

Hello, PM

We need this bug in rhel6.5 and it's fixed already, could you help provide the "pm_ack+","rhel-6.5.0+" and "blocker+" flags for us? 

Thanks,
Qunfang

# rpm -ivh virtio-win-1.6.7-2.el6.noarch.rpm 
Preparing...                ########################################### [100%]
   1:virtio-win             ########################################### [100%]
# cd /usr/share/virtio-win/
]# ls
drivers                     virtio-win-1.6.7.iso      virtio-win.iso
guest-agent                 virtio-win-1.6.7_x86.vfd  virtio-win_x86.vfd
virtio-win-1.6.7_amd64.vfd  virtio-win_amd64.vfd
# cd guest-agent/
# ls
qemu-ga-x64.msi  qemu-ga-x86.msi
# 
# md5sum *
1c98e5435d5900e88bf608aad41a6c6e  qemu-ga-x64.msi
a1d26b4534c2d5aff17255497adbf218  qemu-ga-x86.msi


md5sum for the MSIs in build qemu-ga-win-6.5-4:

[root@qzhang-pc qemu-ga-win-6.5-4]# md5sum *
1c98e5435d5900e88bf608aad41a6c6e  qemu-ga-x64.msi
a1d26b4534c2d5aff17255497adbf218  qemu-ga-x86.msi

As the two msi files have been integrated into virtio-win package, I would like to set this bug status to VERIFIED.

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, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1729.html