RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1183874 - Windows guest(win7/win2012) guest time not sync immediately after execute " virsh domtime $name --sync"
Summary: Windows guest(win7/win2012) guest time not sync immediately after execute " v...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: ---
Assignee: Sameeh Jubran
QA Contact: xiagao
URL:
Whiteboard:
: 1409058 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-20 03:50 UTC by langfang
Modified: 2018-04-10 06:30 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 06:28:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0657 0 None None None 2018-04-10 06:30:38 UTC

Description langfang 2015-01-20 03:50:23 UTC
Description of problem:

Hit this bug when i verify this bug 

Bug 1049040 - (TimeSyncAfterResume) Time sync after resuming from suspend

description:windows guest(win7/win2012) time not update immediately(virsh domtime vm1 --sync) after resumme comment54

Version:

Host:
# uname -r
3.10.0-222.el7.x86_64
 # rpm -q qemu-kvm-rhev
 qemu-kvm-rhev-2.1.2-18.el7.x86_64

Guest:
3.10.0-210.el7.x86_64
virtio-win-1.7.3-1.el7

1.Boot guest


Edit the 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 vm1

3.After guest boot up

 start qemu-ga service in guest


# virsh suspend vm1
Domain vm1 suspended

4.Resume vm1
# virsh resume vm1 && virsh domtime vm1 --sync
Domain vm1 resumed



Actual results:
The guest time not sync immediately

Expected results:


Additional info:

Comment 1 langfang 2015-01-20 03:52:05 UTC
Correct:

Geust:

win7/win2012-64
virtio-win-1.7.3-1.el7

Comment 3 Mike Cao 2015-01-20 05:37:42 UTC
(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

Comment 4 Michal Privoznik 2015-01-20 08:35:53 UTC
I've proposed documentation patch meanwhile the bug is fixed:

https://lists.gnu.org/archive/html/qemu-devel/2015-01/msg02331.html

Comment 9 Marcelo Tosatti 2017-07-18 22:11:00 UTC
*** Bug 1409058 has been marked as a duplicate of this bug. ***

Comment 10 lijin 2017-08-17 07:58:37 UTC
xiago,

Could you try to reproduce this issue with latest version?

Comment 11 xiagao 2017-08-21 09:27:21 UTC
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.

Comment 12 Sameeh Jubran 2017-10-19 16:58:45 UTC
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

Comment 13 Sameeh Jubran 2017-10-19 16:59:00 UTC
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

Comment 14 xiagao 2017-10-20 05:01:19 UTC
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.

Comment 15 Sameeh Jubran 2017-10-22 10:52:58 UTC
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.

Comment 16 xiagao 2017-10-23 03:10:50 UTC
(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

Comment 17 xiagao 2017-10-23 04:51:58 UTC
(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.

Comment 18 Sameeh Jubran 2017-10-23 08:18:05 UTC
> 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.

Comment 19 xiagao 2017-10-23 09:05:33 UTC
(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.

Comment 20 Sameeh Jubran 2017-10-23 10:37:15 UTC
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?

Comment 21 xiagao 2017-10-24 00:52:21 UTC
(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": {}}

Comment 22 Sameeh Jubran 2017-11-01 16:34:24 UTC
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

Comment 23 xiagao 2017-11-03 04:14:50 UTC
(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.

Comment 24 Sameeh Jubran 2017-11-05 09:53:00 UTC
(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?

Comment 25 xiagao 2017-11-06 02:15:51 UTC
(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.

Comment 27 Sameeh Jubran 2017-11-06 15:45:26 UTC
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 =)

Comment 28 xiagao 2017-11-07 06:30:17 UTC
(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.

Comment 29 xiagao 2017-11-07 08:14:20 UTC
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

Comment 30 Sameeh Jubran 2017-11-07 10:27:13 UTC
(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

Comment 32 Michal Privoznik 2017-11-21 13:24:38 UTC
(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.

Comment 33 xiagao 2017-11-22 09:37:17 UTC
(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

Comment 34 lijin 2017-11-22 09:41:48 UTC
change the component back to qemu-ga-win according to comment#33

Comment 36 errata-xmlrpc 2018-04-10 06:28:08 UTC
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


Note You need to log in before you can comment on or make changes to this bug.