Hide Forgot
Created attachment 1212375 [details] windows error if I create snapshot Description of problem: QEMU guest agent VSS Provider is crashed after snapshot deletion. If I create snapshot in Windows VM log is some permission problem. Version-Release number of selected component (if applicable): Windows 2012R2 Qemu guest agent 7.3.2 ovirt guest tools 4.0-1 ovirt engine 4.0.4.4-1 How reproducible: always Steps to Reproduce: 1. create snapshot 2. delete snapshot 3. Actual results: QEMU guest agent VSS Provider is crashed after snapshot deletion Expected results: Additional info: If I create snapshot in ovirt dialog is message: Could not detect Guest Agent on the VM. Note that without a Guest Agent the data on the created snapshot may be inconsistent.
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