Bug 1183874
Summary: | Windows guest(win7/win2012) guest time not sync immediately after execute " virsh domtime $name --sync" | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | langfang <flang> |
Component: | virtio-win | Assignee: | Sameeh Jubran <sjubran> |
virtio-win sub component: | qemu-ga-win | QA Contact: | xiagao |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | low | ||
Priority: | medium | CC: | ailan, chayang, ddepaula, dyuan, juzhang, lijin, lmiksik, mdeng, michen, mprivozn, rbalakri, sjubran, virt-maint, xiagao, xuzhang, zpeng |
Version: | 7.1 | ||
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: | Environment: | ||
Last Closed: | 2018-04-10 06:28:08 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: |
Description
langfang
2015-01-20 03:50:23 UTC
Correct: Geust: win7/win2012-64 virtio-win-1.7.3-1.el7 (In reply to langfang from comment #1) > Correct: > > Geust: > > win7/win2012-64 > virtio-win-1.7.3-1.el7 qemu-ga-win-0.1-10.el7 flang .Pls provide qemu-ga version next time as well I've proposed documentation patch meanwhile the bug is fixed: https://lists.gnu.org/archive/html/qemu-devel/2015-01/msg02331.html *** Bug 1409058 has been marked as a duplicate of this bug. *** xiago, Could you try to reproduce this issue with latest version? Rerpoduced this bug in qemu-ga-win-7.4.5-1 version: 3.10.0-693.el7.x86_64 qemu-kvm-rhev-2.9.0-16.el7.x86_64 win2012-64 qemu-ga-win-7.4.5-1 steps: 1,boot guest with xml ... <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/test.agent'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> ... 2,virsh start kvm-win2012-x86_64-qcow2 3,install vioser driver and qemu-ga in guest,insure qemu-ga service is running check time is the same between host and guest. 4,stop guest # virsh suspend kvm-win2012-x86_64-qcow2 Domain kvm-win2012-x86_64-qcow2 suspended 5.wait about 9 mins 6.# virsh resume kvm-win2012-x86_64-qcow2 Domain kvm-win2012-x86_64-qcow2 resumed 7.virsh domtime kvm-win2012-x86_64-qcow2 --sync check time: host: # date Mon Aug 21 17:14:55 CST 2017 guet: 5:05pm after resume guest and sync time, time is not sync immediately. This issue should be partially fixed in the following version of qemu-ga. Now the commands attempts to sync using the NTP server as there is no way to access the RTC on Windows after boot. https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14305079 This issue should be partially fixed in the following version of qemu-ga. Now the commands attempts to sync using the NTP server as there is no way to access the RTC on Windows after boot. https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14305079 Hi Sameeh, It is still failed with the new build. qemu-ga-win-2.9.1-2.el7ev.noarch virtio-win-prewhql-0.1-142 the steps are the same with https://bugzilla.redhat.com/show_bug.cgi?id=1183874#c11 the result is the time in guest is not syn with host. So reassign this bug. Can you please post the error message you are receiving? And as I stated earlier since there is no way to access the RTC on Windows post boot time we can't really do much if time server is not on or accessible. So there will be cases where we can't do anything but these cases should be accompanied with a suitable error message. (In reply to Sameeh Jubran from comment #15) > Can you please post the error message you are receiving? > > And as I stated earlier since there is no way to access the RTC on Windows > post boot time we can't really do much if time server is not on or > accessible. So there will be cases where we can't do anything but these > cases should be accompanied with a suitable error message. Edit /etc/libvirt/libvirtd.conf log_level = 1 log_filters="1:libvirt" log_outputs="1:file:/var/log/libvirtd_debug.log" rm -f /var/log/libvirt/libvirtd.log service libvirtd restart [root@dhcp-8-178 whql_autotest]# virsh start kvm-win2012-x86_64-qcow2 Domain kvm-win2012-x86_64-qcow2 started [root@dhcp-8-178 whql_autotest]# [root@dhcp-8-178 whql_autotest]# virsh suspend kvm-win2012-x86_64-qcow2 Domain kvm-win2012-x86_64-qcow2 suspended [root@dhcp-8-178 whql_autotest]# virsh resume kvm-win2012-x86_64-qcow2 Domain kvm-win2012-x86_64-qcow2 resumed [root@dhcp-8-178 whql_autotest]# virsh domtime kvm-win2012-x86_64-qcow2 --sync error: internal error: unable to execute QEMU agent command 'guest-set-time': Windows Time service not running on the guest (In reply to xiagao from comment #16) > (In reply to Sameeh Jubran from comment #15) > > Can you please post the error message you are receiving? > > > > And as I stated earlier since there is no way to access the RTC on Windows > > post boot time we can't really do much if time server is not on or > > accessible. So there will be cases where we can't do anything but these > > cases should be accompanied with a suitable error message. > > Edit /etc/libvirt/libvirtd.conf > > log_level = 1 > log_filters="1:libvirt" > log_outputs="1:file:/var/log/libvirtd_debug.log" > rm -f /var/log/libvirt/libvirtd.log > service libvirtd restart > [root@dhcp-8-178 whql_autotest]# virsh start kvm-win2012-x86_64-qcow2 > Domain kvm-win2012-x86_64-qcow2 started > > [root@dhcp-8-178 whql_autotest]# > [root@dhcp-8-178 whql_autotest]# virsh suspend kvm-win2012-x86_64-qcow2 > Domain kvm-win2012-x86_64-qcow2 suspended > > [root@dhcp-8-178 whql_autotest]# virsh resume kvm-win2012-x86_64-qcow2 > Domain kvm-win2012-x86_64-qcow2 resumed > > [root@dhcp-8-178 whql_autotest]# virsh domtime kvm-win2012-x86_64-qcow2 > --sync > error: internal error: unable to execute QEMU agent command > 'guest-set-time': Windows Time service not running on the guest Start "Windows Time service" in guest manualy, retest it. [root@dhcp-8-178 whql_autotest]# virsh suspend kvm-win2012-x86_64-qcow2 Domain kvm-win2012-x86_64-qcow2 suspended [root@dhcp-8-178 whql_autotest]# virsh resume kvm-win2012-x86_64-qcow2 Domain kvm-win2012-x86_64-qcow2 resumed [root@dhcp-8-178 whql_autotest]# virsh domtime kvm-win2012-x86_64-qcow2 --sync There is no error message.But the guest time is not sync with host time immediately.
> There is no error message.But the guest time is not sync with host time immediately.
How much time does it take to sync? It should take few seconds up to a minute. Can you please check the Event viewer for "Event ID 37 — Local Time Synchronization" in the system tab.
(In reply to Sameeh Jubran from comment #18) > > There is no error message.But the guest time is not sync with host time immediately. > > How much time does it take to sync? It should take few seconds up to a > minute. Can you please check the Event viewer for "Event ID 37 — Local Time > Synchronization" in the system tab. It takes more than 5 mins to sync. Did not find "Event ID 37 — Local Time Synchronization" in the system tab of Event viewer. Can you please try and reproduce the issue and then instead of running "--sync" run the following command in the guest's cmd: "w32tm /resync /nowait" How fast the time syncs? does Event ID 37 shows up? What about the command "{"execute":"guest-set-time"}"? try and use it to sync instead of virsh command. How fast the time syncs? does Event ID 37 shows up? (In reply to Sameeh Jubran from comment #20) > Can you please try and reproduce the issue and then instead of running > "--sync" run the following command in the guest's cmd: > > "w32tm /resync /nowait" > > How fast the time syncs? does Event ID 37 shows up? > > What about the command "{"execute":"guest-set-time"}"? try and use it to > sync instead of virsh command. How fast the time syncs? does Event ID 37 > shows up? 1. after resume guest, run "w32tm /resync /nowait" in guest, it also takes more than 5 mins to sync, no Event ID 37 shows up. 2. after resume guest, in host run: {"execute": "guest-set-time", "arguments": {"time": 1508805934000000000}} {"return": {}} time sync immediately, but no Event ID 37 shows up. But when I run "{"execute":"guest-set-time"}",hit another issue. When connet chardev and issue cmd in host, there is no response. # nc -U /var/lib/libvirt/qemu/test.agent {"execute": "guest-set-time", "arguments": {"time": 1508805934000000000}} {"execute":"guest-ping"} {"execute":"guest-info"} {"execute":"guest-info"} after I restart qemu-ga service in guest, there will be response. {"execute":"guest-ping"} {"return": {}} {"execute": "guest-set-time", "arguments": {"time": 1508805934000000000}} {"return": {}} To start the Windows Time service you should: 1. Start -> Run 2. services.msc 3. Search for "Windows Time" 4. Right click -> Start Indeed in Windows 2012 x64 I can't see the Event ID 37 but however the following event should show up: Once you send the command of "{"execute":"guest-set-time"}" you should see this event on the event viewer: Kernel-General Description: The system time has changed to ?2017?-?11?-?01T15:28:39.353000000Z from ?2017?-?11?-?01T15:28:39.355538700Z. Change Reason: An application or system component changed the time. I can't reproduce the issue with qga channel and no response can you please try using this recent build of qga: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14419730 (In reply to Sameeh Jubran from comment #22) > To start the Windows Time service you should: > 1. Start -> Run > 2. services.msc > 3. Search for "Windows Time" > 4. Right click -> Start > > Indeed in Windows 2012 x64 I can't see the Event ID 37 but however the > following event should show up: > > Once you send the command of "{"execute":"guest-set-time"}" you should see > this event on the event viewer: > Kernel-General > Description: > The system time has changed to ?2017?-?11?-?01T15:28:39.353000000Z from > ?2017?-?11?-?01T15:28:39.355538700Z. > Change Reason: An application or system component changed the time. > > I can't reproduce the issue with qga channel and no response can you please > try using this recent build of qga: > > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14419730 1)yes, there is Kernel-General like "The system time has changed..." when I run {"execute":"guest-set-time"} but after run "virsh domtime kvm-win2012-x86_64-qcow2 --sync" ,there is no Kernel-General info in windows event. 2)still no response. but when I restart qemu-ga service in guest. Can get response. [root@dhcp-8-178 home]# virsh start kvm-win2012-x86_64-qcow2 Domain kvm-win2012-x86_64-qcow2 started [root@dhcp-8-178 home]# nc -U /var/lib/libvirt/qemu/test.agent {"execute":"guest-ping"} {"return": {}} [root@dhcp-8-178 home]# virsh suspend kvm-win2012-x86_64-qcow2 Domain kvm-win2012-x86_64-qcow2 suspended [root@dhcp-8-178 home]# virsh resume kvm-win2012-x86_64-qcow2 Domain kvm-win2012-x86_64-qcow2 resumed [root@dhcp-8-178 home]# nc -U /var/lib/libvirt/qemu/test.agent {"execute":"guest-ping"} {"execute":"guest-ping"} Restart qemu-ga service in guest. {"execute":"guest-ping"} {"return": {}} {"execute":"guest-ping"} {"return": {}} Maybe it's the reason why "virsh domtime kvm-win2012-x86_64-qcow2 --sync" does not work. (In reply to xiagao from comment #23) > (In reply to Sameeh Jubran from comment #22) > > To start the Windows Time service you should: > > 1. Start -> Run > > 2. services.msc > > 3. Search for "Windows Time" > > 4. Right click -> Start > > > > Indeed in Windows 2012 x64 I can't see the Event ID 37 but however the > > following event should show up: > > > > Once you send the command of "{"execute":"guest-set-time"}" you should see > > this event on the event viewer: > > Kernel-General > > Description: > > The system time has changed to ?2017?-?11?-?01T15:28:39.353000000Z from > > ?2017?-?11?-?01T15:28:39.355538700Z. > > Change Reason: An application or system component changed the time. > > > > I can't reproduce the issue with qga channel and no response can you please > > try using this recent build of qga: > > > > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14419730 > > > 1)yes, there is Kernel-General like "The system time has changed..." when I > run > {"execute":"guest-set-time"} > > but after run "virsh domtime kvm-win2012-x86_64-qcow2 --sync" ,there is no > Kernel-General info in windows event. > > > 2)still no response. > but when I restart qemu-ga service in guest. Can get response. > > > [root@dhcp-8-178 home]# virsh start kvm-win2012-x86_64-qcow2 > Domain kvm-win2012-x86_64-qcow2 started > > [root@dhcp-8-178 home]# nc -U /var/lib/libvirt/qemu/test.agent > {"execute":"guest-ping"} > {"return": {}} > > [root@dhcp-8-178 home]# virsh suspend kvm-win2012-x86_64-qcow2 > Domain kvm-win2012-x86_64-qcow2 suspended > [root@dhcp-8-178 home]# virsh resume kvm-win2012-x86_64-qcow2 > Domain kvm-win2012-x86_64-qcow2 resumed > > [root@dhcp-8-178 home]# nc -U /var/lib/libvirt/qemu/test.agent > {"execute":"guest-ping"} > {"execute":"guest-ping"} > > Restart qemu-ga service in guest. > {"execute":"guest-ping"} > {"return": {}} > {"execute":"guest-ping"} > {"return": {}} > > Maybe it's the reason why "virsh domtime kvm-win2012-x86_64-qcow2 --sync" > does not work. I can't reproduce this at all, the command works just fine for me. Can you please provide me with your command line? Are you sure that you uninstalled the previous qemu-ga before testing? I tried to reproduce on Windows 2012 x64, is this the one you are using to reproduce? (In reply to Sameeh Jubran from comment #24) > (In reply to xiagao from comment #23) > > (In reply to Sameeh Jubran from comment #22) > > > To start the Windows Time service you should: > > > 1. Start -> Run > > > 2. services.msc > > > 3. Search for "Windows Time" > > > 4. Right click -> Start > > > > > > Indeed in Windows 2012 x64 I can't see the Event ID 37 but however the > > > following event should show up: > > > > > > Once you send the command of "{"execute":"guest-set-time"}" you should see > > > this event on the event viewer: > > > Kernel-General > > > Description: > > > The system time has changed to ?2017?-?11?-?01T15:28:39.353000000Z from > > > ?2017?-?11?-?01T15:28:39.355538700Z. > > > Change Reason: An application or system component changed the time. > > > > > > I can't reproduce the issue with qga channel and no response can you please > > > try using this recent build of qga: > > > > > > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14419730 > > > > > > 1)yes, there is Kernel-General like "The system time has changed..." when I > > run > > {"execute":"guest-set-time"} > > > > but after run "virsh domtime kvm-win2012-x86_64-qcow2 --sync" ,there is no > > Kernel-General info in windows event. > > > > > > 2)still no response. > > but when I restart qemu-ga service in guest. Can get response. > > > > > > [root@dhcp-8-178 home]# virsh start kvm-win2012-x86_64-qcow2 > > Domain kvm-win2012-x86_64-qcow2 started > > > > [root@dhcp-8-178 home]# nc -U /var/lib/libvirt/qemu/test.agent > > {"execute":"guest-ping"} > > {"return": {}} > > > > [root@dhcp-8-178 home]# virsh suspend kvm-win2012-x86_64-qcow2 > > Domain kvm-win2012-x86_64-qcow2 suspended > > [root@dhcp-8-178 home]# virsh resume kvm-win2012-x86_64-qcow2 > > Domain kvm-win2012-x86_64-qcow2 resumed > > > > [root@dhcp-8-178 home]# nc -U /var/lib/libvirt/qemu/test.agent > > {"execute":"guest-ping"} > > {"execute":"guest-ping"} > > > > Restart qemu-ga service in guest. > > {"execute":"guest-ping"} > > {"return": {}} > > {"execute":"guest-ping"} > > {"return": {}} > > > > Maybe it's the reason why "virsh domtime kvm-win2012-x86_64-qcow2 --sync" > > does not work. > > I can't reproduce this at all, the command works just fine for me. > > Can you please provide me with your command line? > qemu-cmd-line: /usr/libexec/qemu-kvm -name guest=kvm-win2012-x86_64-qcow2,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-8-kvm-win2012-x86_64-q/master-key.aes -machine pc-i440fx-rhel7.4.0,accel=kvm,usb=off,dump-guest-core=off -cpu SandyBridge,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 2fec125d-d9f1-440d-ba65-11a39ccf1132 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-8-kvm-win2012-x86_64-q/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/kvm_autotest_root/images/win2012-64-virtio.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:bd:ed:b3,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/test.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on > Are you sure that you uninstalled the previous qemu-ga before testing? > yes, what I used is the latest one. > I tried to reproduce on Windows 2012 x64, is this the one you are using to > reproduce? yes. btw, win10 can also reproduce. I used virsh cmd to produce it. But when I use stop/cont to replace suspend/resume, can't reproduce that issue. I took a look I believe this has nothing to do with qemu-ga for the following reasons: *) I can reproduce with the following steps: 1. Connect to qga channel using ncat (nc -U ..) 2. Run any command, for example "{"execute":"guest-ping"}" -> you should get a reply 3. use Ctrl + c to close the Ncat connection with qga 4. reconnect using ncat (nc -U ..) 5. run any command again -> no reply. *) This seems to be an issue with qemu and it is very similar to this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1043403 *) Try and use a newer version of RHEL/qemu this problem shouldn't exist as I am using fedora and up-to-date qemu and I can't reproduce this at all. *) In case qga-win is actually causing the bug ( which I don't believe it is), it has nothing to do with the "{"execute":"guest-set-time"}" command as it can be reproduced with any other command, so let's VERIFY this BZ and reopen new one if you still believe that qga-win is what causing this bug and will continue the discussion there =) (In reply to Sameeh Jubran from comment #27) > I took a look I believe this has nothing to do with qemu-ga for the > following reasons: > > *) I can reproduce with the following steps: > 1. Connect to qga channel using ncat (nc -U ..) > 2. Run any command, for example "{"execute":"guest-ping"}" -> you > should get a reply > 3. use Ctrl + c to close the Ncat connection with qga > 4. reconnect using ncat (nc -U ..) > 5. run any command again -> no reply. > > *) This seems to be an issue with qemu and it is very similar to this BZ > https://bugzilla.redhat.com/show_bug.cgi?id=1043403 Do you boot up the guest using libvirt method or qemu-kvm command line? I can reproduce it for libvirt method steps: 1)boot up guest with vioser driver and qemu-ga installed. # virsh start kvm-win2012-x86_64-qcow2 2)Connect to qga channel using ncat (nc -U ..) 3Run any command, for example "{"execute":"guest-ping"}" -> no response 4)use Ctrl + c to close the Ncat connection with qga 5)reconnect using ncat (nc -U ..) ->can't connect. Ncat: Invalid argument. 6)restart qemu-ga service in guest 7)reconnect using ncat (nc -U ..) ->success 8)run any command again -> no response 9)restart qemu-ga service in guest 10)Run any command, for example "{"execute":"guest-ping"}" -> get return. {"return": {}} 11)use Ctrl + c to close the Ncat connection with qga 12)reconnect using ncat (nc -U ..) ->success 13)run any command again -> no response Seems must restart qemu-ga service in guest, can get the response from qga channel using ncat. But if boot up guest with qemu command line, can not reproduce that issue. > > *) Try and use a newer version of RHEL/qemu this problem shouldn't exist as > I am using fedora and up-to-date qemu and I can't reproduce this at all. I update qemu to the latest one. Still hit that no reply issue. version: qemu-kvm-rhev-2.10.0-4.el7.x86_64 > > *) In case qga-win is actually causing the bug ( which I don't believe it > is), it has nothing to do with the "{"execute":"guest-set-time"}" command as > it can be reproduced with any other command, so let's VERIFY this BZ and > reopen new one if you still believe that qga-win is what causing this bug > and will continue the discussion there =) I think it's better to verify this bug when no response issue is resolved. Hi Sameeh, Maybe I make some mistake. The "no response" issue is only happend in virsh command. The qga channel seemed be used by libvirt, so there will be no response when I connect to qga channel using ncat. Anyway, 'guest-set-time' always set time successlly.But using "virsh domtime $name --sync" still can't set time. So this bug can't be verified. Can you tell me what did libvirt do when running "virsh domtime $name --sync"? thanks, xiaoling (In reply to xiagao from comment #29) > Hi Sameeh, > Maybe I make some mistake. The "no response" issue is only happend in virsh > command. The qga channel seemed be used by libvirt, so there will be no > response when I connect to qga channel using ncat. No problem :) > > > Anyway, 'guest-set-time' always set time successlly.But using "virsh domtime > $name --sync" still can't set time. So this bug can't be verified. > > Can you tell me what did libvirt do when running "virsh domtime $name > --sync"? Hi xiaoling, I am not that familiar with libvirt code at all, however from a quick look at the libvirt code and I can see few possibilities why this could happen, the function that executes the guest-set-time command is "qemuDomainSetTime" so the issue maybe there. Anyways since the issue now is with libvirt and not qemu-ga I am reassigning the issue. > > thanks, > xiaoling (In reply to xiagao from comment #28) > steps: > 1)boot up guest with vioser driver and qemu-ga installed. > # virsh start kvm-win2012-x86_64-qcow2 > > 2)Connect to qga channel using ncat (nc -U ..) > 3Run any command, for example "{"execute":"guest-ping"}" -> no response > 4)use Ctrl + c to close the Ncat connection with qga > 5)reconnect using ncat (nc -U ..) ->can't connect. Ncat: Invalid argument. > 6)restart qemu-ga service in guest > 7)reconnect using ncat (nc -U ..) ->success > 8)run any command again -> no response > 9)restart qemu-ga service in guest > 10)Run any command, for example "{"execute":"guest-ping"}" -> get return. > {"return": {}} > 11)use Ctrl + c to close the Ncat connection with qga > 12)reconnect using ncat (nc -U ..) ->success > 13)run any command again -> no response Hold on. So you're trying to connect to the same socket that libvirt is trying to connect to? Of course this confuses libvirt and everybody else. > > Seems must restart qemu-ga service in guest, can get the response from qga > channel using ncat. > > But if boot up guest with qemu command line, can not reproduce that issue. > > > > > > > *) Try and use a newer version of RHEL/qemu this problem shouldn't exist as > > I am using fedora and up-to-date qemu and I can't reproduce this at all. > > I update qemu to the latest one. Still hit that no reply issue. > version: qemu-kvm-rhev-2.10.0-4.el7.x86_64 > > > > > *) In case qga-win is actually causing the bug ( which I don't believe it > > is), it has nothing to do with the "{"execute":"guest-set-time"}" command as > > it can be reproduced with any other command, so let's VERIFY this BZ and > > reopen new one if you still believe that qga-win is what causing this bug > > and will continue the discussion there =) > I think it's better to verify this bug when no response issue is resolved. If we can't get any response from qemu-ga it's either qemu-ga or qemu bug. (In reply to Michal Privoznik from comment #32) > (In reply to xiagao from comment #28) > > > steps: > > 9)restart qemu-ga service in guest > > 10)Run any command, for example "{"execute":"guest-ping"}" -> get return. > > {"return": {}} > > 11)use Ctrl + c to close the Ncat connection with qga > > 12)reconnect using ncat (nc -U ..) ->success > > 13)run any command again -> no response > > Hold on. So you're trying to connect to the same socket that libvirt is > trying to connect to? Of course this confuses libvirt and everybody else. You are right. I mentioned it in https://bugzilla.redhat.com/show_bug.cgi?id=1183874#c29 > > > > > Seems must restart qemu-ga service in guest, can get the response from qga > > channel using ncat. > > Retest on the following pkg: qemu-ga-win-2.9.2-2.el7ev.noarch qemu-kvm-rhev-2.9.0-16.el7.x86_64 virtio-win-1.9.3-1.el7.iso Steps like https://bugzilla.redhat.com/show_bug.cgi?id=1183874#c17 But need do following steps after guest boot up except for install virtio-serial driver and qemu-ga-x64.msi pkg. * start Windows Time service in guest. * change Internet Time Server to clock.redhat.com The result is guest sync immediately after execute "virsh domtime kvm-win2012-x86_64-qcow2 --sync" cmd. So this bug is fixed and change the status to verified change the component back to qemu-ga-win according to comment#33 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-2018:0657 |