Bug 1409058

QE could reproduce the issue on the following builds
host
kernel-3.10.0-327.el7.ppc64le
qemu-kvm-rhev-2.3.0-31.el7.ppc64le
guest
kernel-3.10.0-327.46.1.el7.ppc64le

Notes,Time drift is about 5.81s
Reproducible,about 60%

(In reply to dengmin from comment #0)
> Description of problem:
> Time drift is too large after guest stop and cont.
> 
> Version-Release number of selected component (if applicable):
> qemu-kvm-rhev-2.6.0-27.el7.ppc64le
> kernel-3.10.0-514.el7.ppc64le
> 
> How reproducible:
> 3
> 
> Steps to Reproduce:
> 1.Execute command in guest by 
>   date +'TIME: %a %m/%d/%Y %H:%M:%S.%N'
> 2.Stop guest for about 60s
> 3.Continue guest again
> 4.Run command 
>   date +'TIME: %a %m/%d/%Y %H:%M:%S.%N' on guest 
>   date +'TIME: %a %m/%d/%Y %H:%M:%S.%N' on host
> 5.Compare two time stamps 
>   (Notes:the following time are calculated by our automation scripts but it
> also can calculate an approximately value by hand as well)
>   Host duration (iteration 1): 90.18
>   Guest duration (iteration 1): 95.00
>   
> Actual results:
> The time boundary is 3s so I am afraid that 4.81 is a bit large.
> 
> Expected results:
> The time drift should be less than 3s
> 
> Additional info:
> Similar issue can also be found on x86 platform.

The resume procedure should execute a command to sync the guest time upon
continue, as described here (virsh domtime --sync now):
https://bugzilla.redhat.com/show_bug.cgi?id=1049040

So the procedure being tested here is incorrect.

Hi Marcelo,

There is a new scenario that hit the same problem. Pls see below.

Description of problem:
The windows guest can't catch up the host time after stop/cont.

Version-Release number of selected component (if applicable):
3.10.0-668.el7.x86_64
qemu-kvm-rhev-2.9.0-5.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Execute command in guest by 
  Boot the guest with # qemu-kvm ... -net none -rtc base=localtime,clock=host,driftfix=slew.

/usr/libexec/qemu-kvm -M pc -name seabios-test -enable-kvm -m 4G -cpu SandyBridge -smp 4,cores=4,threads=1,sockets=1,maxcpus=4 \
-nodefaults -chardev socket,id=charmonitor,path=/tmp/126NICW10S64SOB,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-vga std \
-vnc :1 \
-qmp tcp:0:6667,server,nowait \
-net none -rtc base=localtime,clock=host,driftfix=slew \
-drive file=/home/kvm-devel/win2016-64-virtio-scsi.qcow2,if=none,id=drive-virtio-0-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop \
-device virtio-scsi-pci,id=scsi \
-device scsi-hd,drive=drive-virtio-0-0,id=drive-scsi,bootindex=1 -boot menu=on \
-device virtio-net-pci,netdev=tap10,mac=64:31:50:23:6e:66,disable-legacy=on,disable-modern=off \
-netdev tap,id=tap10 \
-monitor stdio \

2.stop guest
(qemu) stop
(qemu) info status

3.wait 30 mins then continue guest
(qemu) cont
(qemu) info status

Actual results:
The guest system time is different from the host system after 30+ minutes.

Expected results:
The guest system time should catch up with the host system after 10/20/30 minutes.

Additional info:
The ntp service is on, and this bug would not happen when qemu command is set to the clock=vm.

Thanks for your reply.

(In reply to Sitong Liu from comment #4)
> Hi Marcelo,
> 
> There is a new scenario that hit the same problem. Pls see below.
> 
> Description of problem:
> The windows guest can't catch up the host time after stop/cont.
> 
> Version-Release number of selected component (if applicable):
> 3.10.0-668.el7.x86_64
> qemu-kvm-rhev-2.9.0-5.el7.x86_64
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1.Execute command in guest by 
>   Boot the guest with # qemu-kvm ... -net none -rtc
> base=localtime,clock=host,driftfix=slew.
> 
> /usr/libexec/qemu-kvm -M pc -name seabios-test -enable-kvm -m 4G -cpu
> SandyBridge -smp 4,cores=4,threads=1,sockets=1,maxcpus=4 \
> -nodefaults -chardev
> socket,id=charmonitor,path=/tmp/126NICW10S64SOB,server,nowait \
> -mon chardev=charmonitor,id=monitor,mode=control \
> -vga std \
> -vnc :1 \
> -qmp tcp:0:6667,server,nowait \
> -net none -rtc base=localtime,clock=host,driftfix=slew \
> -drive
> file=/home/kvm-devel/win2016-64-virtio-scsi.qcow2,if=none,id=drive-virtio-0-
> 0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop \
> -device virtio-scsi-pci,id=scsi \
> -device scsi-hd,drive=drive-virtio-0-0,id=drive-scsi,bootindex=1 -boot
> menu=on \
> -device
> virtio-net-pci,netdev=tap10,mac=64:31:50:23:6e:66,disable-legacy=on,disable-
> modern=off \
> -netdev tap,id=tap10 \
> -monitor stdio \
> 
> 2.stop guest
> (qemu) stop
> (qemu) info status
> 
> 3.wait 30 mins then continue guest
> (qemu) cont
> (qemu) info status
> 
> Actual results:
> The guest system time is different from the host system after 30+ minutes.
> 
> Expected results:
> The guest system time should catch up with the host system after 10/20/30
> minutes.
> 
> Additional info:
> The ntp service is on, and this bug would not happen when qemu command is
> set to the clock=vm.
> 
> Thanks for your reply.

Is the guest agent installed in the guest ?
What version is it ?

By using virsh, can you attempt to execute the commands at 
the end of this message:

https://www.redhat.com/archives/libvirt-users/2015-September/msg00099.html

And confirm the guest time is correct ?

(In reply to Marcelo Tosatti from comment #5)
> (In reply to Sitong Liu from comment #4)
> > Hi Marcelo,
> > 
> > There is a new scenario that hit the same problem. Pls see below.
> > 
> > Description of problem:
> > The windows guest can't catch up the host time after stop/cont.
> > 
> > Version-Release number of selected component (if applicable):
> > 3.10.0-668.el7.x86_64
> > qemu-kvm-rhev-2.9.0-5.el7.x86_64
> > 
> > How reproducible:
> > 100%
> > 
> > Steps to Reproduce:
> > 1.Execute command in guest by 
> >   Boot the guest with # qemu-kvm ... -net none -rtc
> > base=localtime,clock=host,driftfix=slew.
> > 
> > /usr/libexec/qemu-kvm -M pc -name seabios-test -enable-kvm -m 4G -cpu
> > SandyBridge -smp 4,cores=4,threads=1,sockets=1,maxcpus=4 \
> > -nodefaults -chardev
> > socket,id=charmonitor,path=/tmp/126NICW10S64SOB,server,nowait \
> > -mon chardev=charmonitor,id=monitor,mode=control \
> > -vga std \
> > -vnc :1 \
> > -qmp tcp:0:6667,server,nowait \
> > -net none -rtc base=localtime,clock=host,driftfix=slew \
> > -drive
> > file=/home/kvm-devel/win2016-64-virtio-scsi.qcow2,if=none,id=drive-virtio-0-
> > 0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop \
> > -device virtio-scsi-pci,id=scsi \
> > -device scsi-hd,drive=drive-virtio-0-0,id=drive-scsi,bootindex=1 -boot
> > menu=on \
> > -device
> > virtio-net-pci,netdev=tap10,mac=64:31:50:23:6e:66,disable-legacy=on,disable-
> > modern=off \
> > -netdev tap,id=tap10 \
> > -monitor stdio \
> > 
> > 2.stop guest
> > (qemu) stop
> > (qemu) info status
> > 
> > 3.wait 30 mins then continue guest
> > (qemu) cont
> > (qemu) info status
> > 
> > Actual results:
> > The guest system time is different from the host system after 30+ minutes.
> > 
> > Expected results:
> > The guest system time should catch up with the host system after 10/20/30
> > minutes.
> > 
> > Additional info:
> > The ntp service is on, and this bug would not happen when qemu command is
> > set to the clock=vm.
> > 
> > Thanks for your reply.
> 
> Is the guest agent installed in the guest ?
> What version is it ?

I test the guest with guest agent, it takes no effect on time sync. The agent version is virtio-win-1.9.1.

> By using virsh, can you attempt to execute the commands at 
> the end of this message:
> 
> https://www.redhat.com/archives/libvirt-users/2015-September/msg00099.html
> 
> And confirm the guest time is correct ?

The guest time is not correct when resume from suspend, by using virsh, and with guest agent running on guest.

Best regards,
Sitong

*** This bug has been marked as a duplicate of bug 1183874 ***