Created attachment 1212376 [details]
windows error after snapshot deletion

Moving to virtio-win according to https://fedoraproject.org/wiki/Windows_Virtio_Drivers

In oVirt guest tools we can only consume a fix provided by virtio-win if available.

Please open a rebase bug for oVirt/ovirt guest tools when / if a fix is available.

To reproduce this bug, use ovirt guest tools 4.0-1 and ovirt engine 4.0.4.4-1 are necessary, right? Please tell me some details, many thanks.

I can not reproduce this bug by the below steps on Windows 2012R2

1. install Qemu guest agent 7.3.2, and start qemu-ga/QEMU guest agent VSS Provider service
2. create snapshot
HMP: #(qemu) snapshot_blkdev drive-virtio-disk-0 /some/place/my-image qcow2
QMP: #{ "execute": "snapshot_blkdev", "arguments": { "device": "drive-virtio-disk-0", "snapshot-file": "/some/place/my-image", "format": "qcow2" } }
3. delete snapshot
4. lookup event viewer in guest, not found QEMU guest agent VSS Provider is crashed

Created attachment 1214484 [details]
Create snapshot - error in ovirt

Created attachment 1214485 [details]
screenshot before deletion

Created attachment 1214486 [details]
screenshot after deletion

I tested it in ovirt 4.0.4.4-1 and 3.6.7.5-1 and situation is same. Qemu GA is installed from oVirt-toolsSetup_4.0-1.fc23.iso. Some screenshots are in attachement.

(In reply to boruvka.michal from comment #7)
> I tested it in ovirt 4.0.4.4-1 and 3.6.7.5-1 and situation is same. Qemu GA
> is installed from oVirt-toolsSetup_4.0-1.fc23.iso. Some screenshots are in
> attachement.

Hi Michal,

Can it be that you have any third-party anti-virus installed and running on your system?

Thanks,
Vadim.

No. There is no antivirus. Its fresh windows instalation.

(In reply to Amnon Ilan from comment #10)
> Xueqiang, Have you managed to reproduce it?


I can not reproduce this bug by the below steps on Windows 2012R2.

host info: kernel-3.10.0-510.el7.x86_64, qemu-kvm-rhev-2.6.0-28.el7

1. install Qemu guest agent 7.3.2, and start qemu-ga/QEMU guest agent VSS Provider service
2. create snapshot
HMP: #(qemu) snapshot_blkdev drive-virtio-disk-0 /some/place/my-image qcow2
QMP: #{ "execute": "snapshot_blkdev", "arguments": { "device": "drive-virtio-disk-0", "snapshot-file": "/some/place/my-image", "format": "qcow2" } }
3. delete snapshot
4. lookup event viewer in guest, not found QEMU guest agent VSS Provider is crashed


This issue maybe due to ovirt guest tools 4.0-1 and ovirt engine 4.0.4.4-1. I will test with ovirt tools.

Hello,
did you find any solution for my problem?
M.

(In reply to boruvka.michal from comment #12)
> Hello,
> did you find any solution for my problem?
> M.

I can not reproduce it under qemu commandline. Suggest you ask libvirt qe for help. Maybe they're familiar with the ovirt tools.

Michal, please have a check of Xueqiang's test in comment#11 and see what's the difference with yours.

could you provide the virtio-serial driver version?
steps:
device manager ---> System Device ---> VirtIO Serial Driver ---> double click ---> select Driver tab ---> Driver Version

Driver Date: 5/30/2016
Driver Version: 62.73.104.11800

Hi all,

I reproduced this bug on Win7-32 guest with virtio-win-1.8.0-1.el6 version. I think the root cause is the qemu-ga cmd of "guest-fsfreeze-freeze/guest-fsfreeze-thaw". 


The following are the detailed info.

host：
kernel:2.6.32-667.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.496.el6.x86_64

guest:
virtio-win-1.8.0-1.el6
win7-32

1.boot up guest with cmd line
 /usr/libexec/qemu-kvm -S -name avocado-vt-vm1 -machine rhel6.6.0 -nodefaults -vga std -m 8G -smp 8 -drive file=/home/win7-32-virtio.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=0 -drive id=drive_virtio,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/usr/share/virtio-win2/virtio-win-1.8.0.iso -device ide-drive,id=virtio,drive=drive_virtio,bootindex=4,bus=ide.1,unit=1 -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=00:52:0a:5c:f1:1d -vnc :1 -rtc base=localtime,clock=host,driftfix=slew -boot order=cd,menu=on -enable-kvm -monitor stdio -qmp tcp:0:1235,server,nowait -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

2.install serial driver and qemu-ga-x86.msi in guest
check windows guest ,qemu-ga and qemu-ga vss provider service is running well

3.Send commands in the host side to freeze guest:
#nc -U /tmp/qga.sock
{"execute":"guest-fsfreeze-status"}
{"return": "thawed"}
{"execute":"guest-fsfreeze-freeze"}
{"return": 2}
{"execute":"guest-fsfreeze-status"}
{"return": "frozen"}


4.Cont to send commands in the host side to thaw guest: 

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

5.Check event viewer => Windows Logs =>Application in guest.

Actual result:
VSS ERROR log occured.(refer the attachment)


Other info:
1. Hit this issue on virtio-win-1.9.0-3.el7 + qemu-kvm-rhev-2.6.0-27.el7.x86_64 version 
2. Hit thie issue on virtio-win-1.7.5-1.el6 , the difference is only hit it when send {"execute":"guest-fsfreeze-thaw"} cmd.

Created attachment 1221502 [details]
qemu-ga-freeze-thaw-error

I think when doing snapshot creation operation on ovirt, qemu actually did "guest-fsfreeze-freeze"+snapshot+"guest-fsfreeze-thaw" operation.

Hi Michal,

 could you help check whether hit this issue when you create snapshot ? 

Thanks
xiagao

(In reply to xiagao from comment #19)
> I think when doing snapshot creation operation on ovirt, qemu actually did
> "guest-fsfreeze-freeze"+snapshot+"guest-fsfreeze-thaw" operation.
> 
> Hi Michal,
> 
>  could you help check whether hit this issue when you create snapshot ? 
> 
> Thanks
> xiagao

Hello xiagao,
if I was reproduced your steps I got same error as you. But ovirt probably call different commands, because in VM I was get different error.
Michal

(In reply to boruvka.michal from comment #20)
> (In reply to xiagao from comment #19)
> > I think when doing snapshot creation operation on ovirt, qemu actually did
> > "guest-fsfreeze-freeze"+snapshot+"guest-fsfreeze-thaw" operation.
> > 
> > Hi Michal,
> > 
> >  could you help check whether hit this issue when you create snapshot ? 
> > 
> > Thanks
> > xiagao
> 
> Hello xiagao,
> if I was reproduced your steps I got same error as you. But ovirt probably
> call different commands, because in VM I was get different error.
> Michal

Hi Michal,

I tried again and i think the error info is the same with you, the error info in attachment,could you check?

BTW,during snapshot creation the guest will momentarily be halted by QEMU to make the data consistent. 
So,when you create snapshot on ovirt,qemu does three things:
1.(agent) guest-fsfreeze-freeze
2.(qemu) snapshot_blkdev drive-ide0-0-0 /home/my-image qcow2
3.(agent) guest-fsfreeze-thaw

Created attachment 1222563 [details]
error info

Michal, could you tell me the difference between your error and mine.

(In reply to xiagao from comment #22)
> Created attachment 1222563 [details]
> error info
> 
> Michal, could you tell me the difference between your error and mine.

I have in log some permission error:

Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface.  hr = 0x80070005, Access is denied.
. This is often caused by incorrect security settings in either the writer or requestor process. 

Operation:
   Gathering Writer Data

Context:
   Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220}
   Writer Name: System Writer
   Writer Instance ID: {e6c095ec-b8a4-4891-a86e-cf1900687685}

(In reply to boruvka.michal from comment #23)
> (In reply to xiagao from comment #22)
> > Created attachment 1222563 [details]
> > error info
> > 
> > Michal, could you tell me the difference between your error and mine.
> 
> I have in log some permission error:
> 
> Volume Shadow Copy Service error: Unexpected error querying for the
> IVssWriterCallback interface.  hr = 0x80070005, Access is denied.
> . This is often caused by incorrect security settings in either the writer
> or requestor process. 
> 
> Operation:
>    Gathering Writer Data
> 
> Context:
>    Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220}
>    Writer Name: System Writer
>    Writer Instance ID: {e6c095ec-b8a4-4891-a86e-cf1900687685}

Thanks for your quick response.
I tried win2012r2-64 guest, hit the same error above when do guest-fsfreeze-freeze action. hit another error when do uest-fsfreeze-thaw action.
refer to the following attachment.

Created attachment 1222612 [details]
freeze-error

Created attachment 1222613 [details]
thaw-error

Hi xiagao,
Yes. I have the same error. But this thaw-error arrives only, if the time limit is exceeded. 
Michal

(In reply to boruvka.michal from comment #27)
> Hi xiagao,
> Yes. I have the same error. But this thaw-error arrives only, if the time
> limit is exceeded. 
> Michal

Hi Michal,

 Does vss service crash everytime when you create snapshot and delete snapshot?

Thanks,
xiagao

Hi xiagao,
vss service crashes everytime when I create snapshot by ovirt. If I call freeze/thaw by hand without creating snapshot, in VM are the same errors, but service VSS don't crash.
M.

Created attachment 1224529 [details]
create and delete snapshot by rhevm

Test with rhevm env.

hypervisor: qemu-kvm-rhev-2.6.0-27.el7.x86_64
virtio-win: virtio-win-1.9.0.iso
vm: win2012-r2

Tested with rhevm 
1.install win2012r2 guest with rhevm
2.install qemu-ga in guest and start qemu guest agent vss service
QEMU Guest Agent and QEMU Guest Agent VSS Provider are running status

3.create snapshot with rhevm
prompt a tip:
"Could not detect Guest Agent on the VM.Note that without a Guest Agent the data on the created snapshot may be inconsistent."
Continue to create sn successfully and there is no error and vss crash in guest.(refer to the attachment)
windows event viewer: The VSS service is shutting down due to idle timeout.

4.delete snapshot
successful and no error in guest.

Hello,
I have tested it in RHEV too. I have in RHEV VM same permission errors as in ovirt VM. The VSS is crashed after create/delete snapshot.
If I create snapshot, I have no error in RHEV GUI: "Could not detect Guest Agent on ..."

Red Hat Virtualization Manager Version: 4.0.5.5-0.1.el7ev
hypervisor: qemu-kvm-rhev-2.6.0-27.el7.x86_64
qemu GA: 7.3.2
VM: fresh W2012R2 installation

M.

Hi xiagao,
did you find any sollution?
M.

(In reply to boruvka.michal from comment #32)
> Hi xiagao,
> did you find any sollution?
> M.

Michal hi,

I didn't reproduce the bug. 
I was blocked with RHEVM GUI: "Could not detect Guest Agent on ..." , but i checked the vm and find the qemu-guest-agent and qemu-guest-agent vss services were running well. 

Red Hat Virtualization Manager Version: 4.0.6-0.1.el7ev
hypervisor: qemu-kvm-rhev-2.6.0-27.el7.x86_64
qemu GA: 7.3.2
VM: fresh W2012R2 installation

Hi Yan,

For comment 23's error info , i can reproduce it but no VSS crash when i run guest-fsfreeze-freeze cmd. 

Is there any relation between vss error and vss crash?

Do you have any idea about this bug?

Thanks,
xiagao

(In reply to xiagao from comment #34)
> Hi Yan,
> 
> For comment 23's error info , i can reproduce it but no VSS crash when i run
> guest-fsfreeze-freeze cmd. 
> 
> Is there any relation between vss error and vss crash?
> 
> Do you have any idea about this bug?
> 
> Thanks,
> xiagao

I am looking into this bug now

Can you please try the following:

Cause:
Note: If this error is logged along with Event ID 12293, please see KB article Error: VSS Snapshot Creation Failed.

This error is caused by incorrect or missing COM access permissions and does not affect the use of Image for Windows.

Solution:

To set the correct permissions and prevent the error from occurring, follow the instructions below:

1. Press and hold the Windows key and press R to pull up the Run dialog. Alternatively, if Run... is available from the Start Menu you can access it from there.

2. Type dcomcnfg into the box and click OK. The Component Services window will appear.

3.In the left portion of the window, expand the Component Services section and then expand the Computers section.

4. Right-click on My Computer (listed in the Computers section) and select Properties from the pop-up menu.

5. Click the COM Security tab. The My Computer Properties dialog will appear.

6. Click the Edit Default... button in the Access Permissions section. The Access Permission dialog will appear.

7. Under the Group or user names box, click the Add... button.

8. Type Network Service into the box and click OK.

9. Click OK on both the Access Permission and My Computer Properties dialogs to close them.

10. Restart Windows.

(In reply to Yan Vugenfirer from comment #36)
> Can you please try the following:
> 
> Cause:
> Note: If this error is logged along with Event ID 12293, please see KB
> article Error: VSS Snapshot Creation Failed.
> 
> This error is caused by incorrect or missing COM access permissions and does
> not affect the use of Image for Windows.
> 
> Solution:
> 
> To set the correct permissions and prevent the error from occurring, follow
> the instructions below:
> 
> 1. Press and hold the Windows key and press R to pull up the Run dialog.
> Alternatively, if Run... is available from the Start Menu you can access it
> from there.
> 
> 2. Type dcomcnfg into the box and click OK. The Component Services window
> will appear.
> 
> 3.In the left portion of the window, expand the Component Services section
> and then expand the Computers section.
> 
> 4. Right-click on My Computer (listed in the Computers section) and select
> Properties from the pop-up menu.
> 
> 5. Click the COM Security tab. The My Computer Properties dialog will appear.
> 
> 6. Click the Edit Default... button in the Access Permissions section. The
> Access Permission dialog will appear.
> 
> 7. Under the Group or user names box, click the Add... button.
> 
> 8. Type Network Service into the box and click OK.
> 
> 9. Click OK on both the Access Permission and My Computer Properties dialogs
> to close them.
> 
> 10. Restart Windows.



Befor setting the COM access permissions, hit Event ID 12293,8194.

Reproduce steps:
1.start win2012-64 guest with serial driver
2.install serial driver and qemu-ga-x86.msi in guest
3.Send commands in the host side to freeze guest:
#nc -U /tmp/qga.sock
{"execute":"guest-fsfreeze-freeze"}
{"return": 2}
4.check Computer management=>Event Viewer=>Windows Logs=>Application, hit 8194 or 12293 error.



Add Network Service access permission to COM Security as your solution 

Run=>input dcomcnfg and enter=>Componet Services=>Computers=>My computer=>Properties=>COM Security=>Edit default(Access permissions)=>Add=>Type Network Service=>ok... =>restart guest

Reproduce steps:
1.start win2012-64 guest with serial driver
2.install serial driver and qemu-ga-x86.msi in guest
3.Send commands in the host side to freeze guest:
#nc -U /tmp/qga.sock
{"execute":"guest-fsfreeze-freeze"}
{"return": 2}
4.check Computer management=>Event Viewer=>Windows Logs=>Application
no 8194 or 12293 error.


Michal hi,

Could you please add that solution to your env and check if there is crash?

Thanks
xiagao

(In reply to xiagao from comment #37)
> (In reply to Yan Vugenfirer from comment #36)
> > Can you please try the following:
> > 
> > Cause:
> > Note: If this error is logged along with Event ID 12293, please see KB
> > article Error: VSS Snapshot Creation Failed.
> > 
> > This error is caused by incorrect or missing COM access permissions and does
> > not affect the use of Image for Windows.
> > 
> > Solution:
> > 
> > To set the correct permissions and prevent the error from occurring, follow
> > the instructions below:
> > 
> > 1. Press and hold the Windows key and press R to pull up the Run dialog.
> > Alternatively, if Run... is available from the Start Menu you can access it
> > from there.
> > 
> > 2. Type dcomcnfg into the box and click OK. The Component Services window
> > will appear.
> > 
> > 3.In the left portion of the window, expand the Component Services section
> > and then expand the Computers section.
> > 
> > 4. Right-click on My Computer (listed in the Computers section) and select
> > Properties from the pop-up menu.
> > 
> > 5. Click the COM Security tab. The My Computer Properties dialog will appear.
> > 
> > 6. Click the Edit Default... button in the Access Permissions section. The
> > Access Permission dialog will appear.
> > 
> > 7. Under the Group or user names box, click the Add... button.
> > 
> > 8. Type Network Service into the box and click OK.
> > 
> > 9. Click OK on both the Access Permission and My Computer Properties dialogs
> > to close them.
> > 
> > 10. Restart Windows.
> 
> 
> 
> Befor setting the COM access permissions, hit Event ID 12293,8194.
> 
> Reproduce steps:
> 1.start win2012-64 guest with serial driver
> 2.install serial driver and qemu-ga-x86.msi in guest
> 3.Send commands in the host side to freeze guest:
> #nc -U /tmp/qga.sock
> {"execute":"guest-fsfreeze-freeze"}
> {"return": 2}
> 4.check Computer management=>Event Viewer=>Windows Logs=>Application, hit
> 8194 or 12293 error.
> 
> 
> 
> Add Network Service access permission to COM Security as your solution 
> 
> Run=>input dcomcnfg and enter=>Componet Services=>Computers=>My
> computer=>Properties=>COM Security=>Edit default(Access
> permissions)=>Add=>Type Network Service=>ok... =>restart guest
> 
> Reproduce steps:
> 1.start win2012-64 guest with serial driver
> 2.install serial driver and qemu-ga-x86.msi in guest
> 3.Send commands in the host side to freeze guest:
> #nc -U /tmp/qga.sock
> {"execute":"guest-fsfreeze-freeze"}
> {"return": 2}
> 4.check Computer management=>Event Viewer=>Windows Logs=>Application
> no 8194 or 12293 error.
> 
> 
> Michal hi,
> 
> Could you please add that solution to your env and check if there is crash?
> 
> Thanks
> xiagao

Yan hi,

I tested it again, still hit Event ID 12293 after adding Network Service access permission to COM Security as your solution, but the 12293 id event comes about 50s later.

 Michal hi,
 
 Could you please add that solution from comment 36 to your env and check if there is crash?
 
 Thanks
 xiagao

Hi,
now I have in Event log this:
Event ID: 4879
MSDTC encountered an error (HR=0x80000171) while attempting to establish a secure connection with system W12T1.
and 3 min later
Event ID: 8224
The VSS service is shutting down due to idle timeout. 

And QEMU Guest Agent VSS Provider is crashed now.

M.

(In reply to boruvka.michal from comment #40)
> Hi,
> now I have in Event log this:
> Event ID: 4879
> MSDTC encountered an error (HR=0x80000171) while attempting to establish a
> secure connection with system W12T1.
> and 3 min later
> Event ID: 8224
> The VSS service is shutting down due to idle timeout. 
> 
> And QEMU Guest Agent VSS Provider is crashed now.
> 
> M.

Yan hi,

Could you pls check this comment and comment 38 ?

thanks

(In reply to xiagao from comment #41)
> (In reply to boruvka.michal from comment #40)
> > Hi,
> > now I have in Event log this:
> > Event ID: 4879
> > MSDTC encountered an error (HR=0x80000171) while attempting to establish a
> > secure connection with system W12T1.
> > and 3 min later
> > Event ID: 8224
> > The VSS service is shutting down due to idle timeout. 
> > 
> > And QEMU Guest Agent VSS Provider is crashed now.
> > 
> > M.
> 
> Yan hi,
> 
> Could you pls check this comment and comment 38 ?
> 
> thanks

I am continue to looking into it

Hi,

I am seeing the same behaviour with windows 2012 R2 on top of a KVM backed Openstack while running Qemu Guest Tools version 7.2.1 and 7.3.2 (including matched Serial driver).

Before making any changes to COM Security I receive the Volume Shadow copy errors, once I have added Network Services to the COM Permission I see a MSDTC error as above.

Editing the "Local DTC" Security, Allowing Network DTC Access and "Transaction Manager Communication" with anonymous permission stops the "MSDTC" Errors from showing in the Event Log BUT!

The VVS writers are not being engaged with a snapshot and no windows event logs of any related kind are being raised, so it is a little difficult to trouble shoot further {unless there is a Qeum log file hidden in the guest somewhere)?

For reference I am using the Cloudbase windows Eval image (should make it more straight forward to replicate), mounted on Ceph in a RAW format (non-Quiescent Snaps work perfectly).

Test it in qemu-ga-win-7.4.2-1 and virtio-win-1.9.0-3.el7.


Steps:
1.boot up Win2012r2 guest with virtio serial device.
2.install virtio serial driver
3.install qemu-ga-x64.msi in guest
4.Add Network Service access permission to COM Security as your solution 
 Run=>input dcomcnfg and enter=>Componet Services=>Computers=>My
 computer=>Properties=>COM Security=>Edit default(Access
 permissions)=>Add=>Type Network Service=>ok... =>restart guest
5.Send commands in the host side to freeze guest:
 #nc -U /tmp/qga.sock
 {"execute":"guest-fsfreeze-freeze"}
 {"return": 2}
 {"execute":"guest-fsfreeze-thaw"}
 {"return": 2}
6.check Computer management=>Event Viewer=>Windows Logs=>Application

Actual result:
Thereis no vss error.

Bug have a warning log in Event log this:
Event ID: 4879
MSDTC encountered an error (HR=0x80000171) while attempting to establish a secure connection with system WIN-TOKCUGHM6RV.

And 5 mins later
Event ID: 8224
The VSS service is shutting down due to idle timeout. 


Reproduced,so set ASSIGNED status.

(In reply to xiagao from comment #45)
> Test it in qemu-ga-win-7.4.2-1 and virtio-win-1.9.0-3.el7.
> 
> 
> Steps:
> 1.boot up Win2012r2 guest with virtio serial device.
> 2.install virtio serial driver
> 3.install qemu-ga-x64.msi in guest
> 4.Add Network Service access permission to COM Security as your solution 
>  Run=>input dcomcnfg and enter=>Componet Services=>Computers=>My
>  computer=>Properties=>COM Security=>Edit default(Access
>  permissions)=>Add=>Type Network Service=>ok... =>restart guest
> 5.Send commands in the host side to freeze guest:
>  #nc -U /tmp/qga.sock
>  {"execute":"guest-fsfreeze-freeze"}
>  {"return": 2}
>  {"execute":"guest-fsfreeze-thaw"}
>  {"return": 2}
> 6.check Computer management=>Event Viewer=>Windows Logs=>Application
> 
> Actual result:
> Thereis no vss error.
> 
> Bug have a warning log in Event log this:
> Event ID: 4879
> MSDTC encountered an error (HR=0x80000171) while attempting to establish a
> secure connection with system WIN-TOKCUGHM6RV.
> 
> And 5 mins later
> Event ID: 8224
> The VSS service is shutting down due to idle timeout. 
> 
> 
> Reproduced,so set ASSIGNED status.
Someone correct me if I'm wrong, but;

I think you are missing the point here. There is no VSS Snapshot taken when you quiesce a guest machine. It simply flushes and holds writes for a couple of seconds so the hypervisor can take the snapshot and create the delta file. After that it releases writes so the guest continues writing (to the new delta file). Don't expect to see VSS taking an actual snapshot - that's not what VSS is used for here. 

I think the error about MSDTC is a red herring, however it was easily fixed by what James said in Comment 43.

(In reply to Nick Koefoed from comment #46)
> (In reply to xiagao from comment #45)
> > Test it in qemu-ga-win-7.4.2-1 and virtio-win-1.9.0-3.el7.
> > 
> > 
> > Steps:
> > 1.boot up Win2012r2 guest with virtio serial device.
> > 2.install virtio serial driver
> > 3.install qemu-ga-x64.msi in guest
> > 4.Add Network Service access permission to COM Security as your solution 
> >  Run=>input dcomcnfg and enter=>Componet Services=>Computers=>My
> >  computer=>Properties=>COM Security=>Edit default(Access
> >  permissions)=>Add=>Type Network Service=>ok... =>restart guest
> > 5.Send commands in the host side to freeze guest:
> >  #nc -U /tmp/qga.sock
> >  {"execute":"guest-fsfreeze-freeze"}
> >  {"return": 2}
> >  {"execute":"guest-fsfreeze-thaw"}
> >  {"return": 2}
> > 6.check Computer management=>Event Viewer=>Windows Logs=>Application
> > 
> > Actual result:
> > Thereis no vss error.
> > 
> > Bug have a warning log in Event log this:
> > Event ID: 4879
> > MSDTC encountered an error (HR=0x80000171) while attempting to establish a
> > secure connection with system WIN-TOKCUGHM6RV.
> > 
> > And 5 mins later
> > Event ID: 8224
> > The VSS service is shutting down due to idle timeout. 
> > 
> > 
> > Reproduced,so set ASSIGNED status.
> Someone correct me if I'm wrong, but;
> 
> I think you are missing the point here. There is no VSS Snapshot taken when
> you quiesce a guest machine. It simply flushes and holds writes for a couple
> of seconds so the hypervisor can take the snapshot and create the delta
> file. After that it releases writes so the guest continues writing (to the
> new delta file). Don't expect to see VSS taking an actual snapshot - that's
> not what VSS is used for here. 
> 
> I think the error about MSDTC is a red herring, however it was easily fixed
> by what James said in Comment 43.

Correct. The main question is - if hypervisor did the expected work or not.

(In reply to Yan Vugenfirer from comment #47)
> (In reply to Nick Koefoed from comment #46)
> > (In reply to xiagao from comment #45)
> > > Test it in qemu-ga-win-7.4.2-1 and virtio-win-1.9.0-3.el7.
> > > 
> > > 
> > > Steps:
> > > 1.boot up Win2012r2 guest with virtio serial device.
> > > 2.install virtio serial driver
> > > 3.install qemu-ga-x64.msi in guest
> > > 4.Add Network Service access permission to COM Security as your solution 
> > >  Run=>input dcomcnfg and enter=>Componet Services=>Computers=>My
> > >  computer=>Properties=>COM Security=>Edit default(Access
> > >  permissions)=>Add=>Type Network Service=>ok... =>restart guest
> > > 5.Send commands in the host side to freeze guest:
> > >  #nc -U /tmp/qga.sock
> > >  {"execute":"guest-fsfreeze-freeze"}
> > >  {"return": 2}
> > >  {"execute":"guest-fsfreeze-thaw"}
> > >  {"return": 2}
> > > 6.check Computer management=>Event Viewer=>Windows Logs=>Application
> > > 
> > > Actual result:
> > > Thereis no vss error.
> > > 
> > > Bug have a warning log in Event log this:
> > > Event ID: 4879
> > > MSDTC encountered an error (HR=0x80000171) while attempting to establish a
> > > secure connection with system WIN-TOKCUGHM6RV.
> > > 
> > > And 5 mins later
> > > Event ID: 8224
> > > The VSS service is shutting down due to idle timeout. 
> > > 
> > > 
> > > Reproduced,so set ASSIGNED status.
> > Someone correct me if I'm wrong, but;
> > 
> > I think you are missing the point here. There is no VSS Snapshot taken when
> > you quiesce a guest machine. It simply flushes and holds writes for a couple
> > of seconds so the hypervisor can take the snapshot and create the delta
> > file. After that it releases writes so the guest continues writing (to the
> > new delta file). Don't expect to see VSS taking an actual snapshot - that's
> > not what VSS is used for here. 
> > 
> > I think the error about MSDTC is a red herring, however it was easily fixed
> > by what James said in Comment 43.
> 
> Correct. The main question is - if hypervisor did the expected work or not.

Thanks Yan and Nick, QE will verify this bug in hypervisor.
Btw, i have two questions.
> > > 4.Add Network Service access permission to COM Security as your solution
1.Is the step 4 is necessary to create snapshot in hypervisor. 

> > Event ID: 8224
> > The VSS service is shutting down due to idle timeout. 
2. What does thie error mean? 

Thanks,
xiagao

Hi Xiagao,
1. I think Step 4 is necessary, however if you don't see VSS/volsnap/timeout errors in Windows, I think the quiesce was successful. The MSDTC error might be a red herring, however it doesn't hurt to fix it so we don't get the errors in the event logs, right? The fix is quite simple anyway. 
2. This is not an error. This is an informational event log whereby the system is saying VSS hasn't received any commands for a while, so it's shutting itself down. If you do another quiesce snapshot you'll probably see an event for it to start back up again.

I'm not sure what you mean by "QE will verify this bug in hypervisor" - I'm quite new to all this (although an experienced windows Sysadmin) - but this doesn't seem like a Red-Hat/KVM bug to me, more a configuration misalignment :) 

Best regards

So, in response to Yan's post, if you don't see any errors about failure to flush & hold writes, or VSS permission denied, the hypervisor has infact done the correct work in quiesceing the guest file system!

(In reply to Nick Koefoed from comment #49)
> Hi Xiagao,
> 1. I think Step 4 is necessary, however if you don't see VSS/volsnap/timeout
> errors in Windows, I think the quiesce was successful. The MSDTC error might
> be a red herring, however it doesn't hurt to fix it so we don't get the
> errors in the event logs, right? The fix is quite simple anyway. 
> 2. This is not an error. This is an informational event log whereby the
> system is saying VSS hasn't received any commands for a while, so it's
> shutting itself down. If you do another quiesce snapshot you'll probably see
> an event for it to start back up again.
> 
> I'm not sure what you mean by "QE will verify this bug in hypervisor" - I'm
> quite new to all this (although an experienced windows Sysadmin) - but this
> doesn't seem like a Red-Hat/KVM bug to me, more a configuration misalignment
> :) 
> 
> Best regards

Nick hi,
Thanks for your quick response and nice explaination.
About "QE will verify this bug in hypervisor" I mean verifing  comment 0 and comment 23's issue in hypervisor env.

BR,
xiagao

Thanks Xiagao. I understand now. 

Comment 0 and 23 is not a Hypervisor issue - it's windows configuration. Correctly setting DCOM will resolve this. His other "error" is just VSS shutting down due to idle timeout - not an issue at all :) 

boruvka.michal - we need more information, have you tried the suggested Windows configuration fixes? I did this last night and now my snapshots (KVM) and quiesce's (Guest) work perfectly.

>>> > > The VSS service is shutting down due to idle timeout. 

In any case the behaviour will be in the new build not to run VSS qemu-gaservice always, but only when snapshot is requested.

>not to run VSS qemu-gaservice always

This won't matter as it's the Windows VSS service that's shutting down due to idle timeout. So you'll still get this message after a Quiesce is performed anyway, because it turns itself off when it's done ;)

Hi,
I tested it with qemu-ga 7.4.4. It works fine after correct DCOM setting.
Could you set DCOM permission during installation qemu-ga?
M.

(In reply to boruvka.michal from comment #55)
> Hi,
> I tested it with qemu-ga 7.4.4. It works fine after correct DCOM setting.
> Could you set DCOM permission during installation qemu-ga?
> M.

Hi Yan,
Could you help to answer this question?

thanks,
xiagao

(In reply to boruvka.michal from comment #55)
> Hi,
> I tested it with qemu-ga 7.4.4. It works fine after correct DCOM setting.
> Could you set DCOM permission during installation qemu-ga?
> M.

Let's open new BZ for this.

change status to verified according to comment#55.

open a new bug(bz1444702) to track DCOM permission issue

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.

https://access.redhat.com/errata/RHBA-2017:2341