Hi everyone.

I noticed the same problem here.
Specially when clock is defined as UTC (-rtc base=utc).
When qemu runs with the clock settings as "localtime", it does not occur.

Maybe, this issue is related to mc146818rtc hardware. The clock value must be redefined when the machine is restored. But, What are the consequences of a real time application when you redefine the clock settings?

Steps to reproduce:

root# virsh
virsh # managedsave Ubuntu
[after a while...]
virsh # start Ubuntu

(In reply to Julio Cesar Faracco from comment #8)
> Hi everyone.
> 
> I noticed the same problem here.
> Specially when clock is defined as UTC (-rtc base=utc).
> When qemu runs with the clock settings as "localtime", it does not occur.
> 
> Maybe, this issue is related to mc146818rtc hardware. The clock value must
> be redefined when the machine is restored. But, What are the consequences of
> a real time application when you redefine the clock settings?
> 
> Steps to reproduce:
> 
> root# virsh
> virsh # managedsave Ubuntu
> [after a while...]
> virsh # start Ubuntu

Julio,

To sync the guests clock, the following command should be issued:

virsh qemu-agent-command $dom '{"execute":"guest-set-time"}'
virsh qemu-monitor-command $dom '{"execute":"rtc-reset-reinjection"}'

Provided the guests support guest-set-time properly.

Verify this bug with qemu-kvm-0.12.1.2-2.458.el6.x86_64 and with qemu-guest-agent-0.12.1.2-2.458.el6.x86_64 installed in both host and guest.

Steps:

1.Boot guest with virtagent 
# /usr/libexec/qemu-kvm -cpu Opteron_G1  -enable-kvm -m 100G -smp 12,sockets=1,cores=12,threads=1 -name rhel6  -drive file=/mnt/rhel6.7cp2.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0 -boot menu=on -monitor stdio -netdev tap,id=hostnet0,script=/etc/qemu-ifup,vhost=on -device virtio-net-pci,netdev=hostnet0,mac=54:52:00:1a:2c:01,id=test -nodefaults -nodefconfig -spice port=5910,seamless-migration=on,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -qmp unix:/tmp/q1,server,nowait -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0 -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0

2.check guest time, and make sure qemu-ga is running

# date
Mon Mar 16 05:25:42 EDT 2015
# service qemu-ga status
qemu-ga (pid  2778) is running...



3.Stop guest:
(qemu) stop

4.wait for 10+ minutes, then continue guest:
(qemu) c

Check guest time:

# date
Mon Mar 16 05:25:48 EDT 2015

5.Execute "guest-set-time" via virtagent
# nc -U /tmp/qga.sock 
{"execute":"guest-ping"}
{"return": {}}
{"execute":"guest-set-time"}
{"return": {}}


6.Check time inside guest again:
# date
Mon Mar 16 05:38:10 EDT 2015


the time is synced with host, so this bug is fixed.

Hi, Marcelo

Is above right for verify this bug, could you help have a look, then we can set it as verified.

Thanks,
Qian

Retest this bug with windows2012r2 guest:
# /usr/libexec/qemu-kvm -cpu SandyBridge -enable-kvm -m 4G -smp 4,sockets=1,cores=4,threads=1 -name rhel7base  -rtc base=localtime,clock=host,driftfix=none -drive file=/home/win212r2.qcow2,if=none,id=drive-ide-disk0,format=qcow2,werror=stop,rerror=stop,cache=none,aio=native -device ide-drive,drive=drive-ide-disk0,id=ide0 -boot menu=on -monitor stdio  -nodefaults -nodefconfig -spice port=5910,seamless-migration=on,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0  -netdev tap,id=hostnet0,fd=5,vhost=on 5<>/dev/tap5 -device virtio-net-pci,netdev=hostnet0,ctrl_guest_offloads=off,id=vnet0,mac=6e:24:07:a6:63:23  -qmp unix:/tmp/q1,server,nowait -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0 -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0

Have virtio-win-1.7.3-1.el7 installed inside:
virtio-serial build: 62.71.104.9400
qemu-ga build: 7.0.0.10

steps:
1.Start guest

2.stop guest, and record the time

3.after 10 minutes, resume guest.

4.Check time inside guest, the time is still 10minutes ago

5.# nc -U /tmp/qga.sock 
{"execute":"guest-ping"}
{"return": {}}
{"execute":"guest-set-time"}
{"return": {}}


Result:
1. The time is not synced inside guest, is still the time 10minutes ago.
2. Every time do "{"execute":"guest-set-time"}" , the qmp will output sth like this:
{"timestamp": {"seconds": 1426847421, "microseconds": 107634}, "event": "RTC_CHANGE", "data": {"offset": -814}}



Additional info:
1. whether do '{"execute":"rtc-reset-reinjection"}', no affect the test result.

2.even test with -rtc base=localtime,clock=host,driftfix=slew , same result.

3.and test with -rtc base=localtime,driftfix=none, same result.

4.According to bug 1071499 , it is not fixed already.

> 
> 4.According to bug 1071499 , it is not fixed already.

not fixed already / not fixed yet.

Additional info:
Retest windows7 64bit guest with 
-rtc base=localtime,clock=host,driftfix=slew
steps as comment 14

After stop the guest for a  while(I stop it for 10+ minutes), then continue guest, the time of the guest will try to catch up host time crazily, and then
do qmp command
{"execute":"rtc-reset-reinjection"}

, the time device of guest will run normally, but did not sync the host time, then I try to use agent command:
{"execute":"guest-set-time"}

but this command is not working as linux guest, the guest time did not sync as the host time.

(In reply to Qian Guo from comment #13)
> Verify this bug with qemu-kvm-0.12.1.2-2.458.el6.x86_64 and with
> qemu-guest-agent-0.12.1.2-2.458.el6.x86_64 installed in both host and guest.
> 
> Steps:
> 
> 1.Boot guest with virtagent 
> # /usr/libexec/qemu-kvm -cpu Opteron_G1  -enable-kvm -m 100G -smp
> 12,sockets=1,cores=12,threads=1 -name rhel6  -drive
> file=/mnt/rhel6.7cp2.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,
> werror=stop,rerror=stop,aio=native -device
> virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0 -boot menu=on
> -monitor stdio -netdev tap,id=hostnet0,script=/etc/qemu-ifup,vhost=on
> -device virtio-net-pci,netdev=hostnet0,mac=54:52:00:1a:2c:01,id=test
> -nodefaults -nodefconfig -spice
> port=5910,seamless-migration=on,disable-ticketing -vga qxl -global
> qxl-vga.vram_size=67108864 -global PIIX4_PM.disable_s3=0 -global
> PIIX4_PM.disable_s4=0 -qmp unix:/tmp/q1,server,nowait -device
> virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0 -chardev
> socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device
> virtserialport,chardev=qga0,name=org.qemu.guest_agent.0
> 
> 2.check guest time, and make sure qemu-ga is running
> 
> # date
> Mon Mar 16 05:25:42 EDT 2015
> # service qemu-ga status
> qemu-ga (pid  2778) is running...
> 
> 
> 
> 3.Stop guest:
> (qemu) stop
> 
> 4.wait for 10+ minutes, then continue guest:
> (qemu) c
> 
> Check guest time:
> 
> # date
> Mon Mar 16 05:25:48 EDT 2015
> 
> 5.Execute "guest-set-time" via virtagent
> # nc -U /tmp/qga.sock 
> {"execute":"guest-ping"}
> {"return": {}}
> {"execute":"guest-set-time"}
> {"return": {}}
> 
> 
> 6.Check time inside guest again:
> # date
> Mon Mar 16 05:38:10 EDT 2015
> 
> 
> the time is synced with host, so this bug is fixed.
> 
> Hi, Marcelo
> 
> Is above right for verify this bug, could you help have a look, then we can
> set it as verified.
> 
> Thanks,
> Qian

Yes this is correct.

Hi, Marcelo

Do you mean that no need test the windows guest(it need windows qemu-ga driver) for this bug, since just Linux guest can pass this bug ?

Just want to double confirm with you.

Thanks,
Qian

(In reply to Qian Guo from comment #18)
> Hi, Marcelo
> 
> Do you mean that no need test the windows guest(it need windows qemu-ga
> driver) for this bug, since just Linux guest can pass this bug ?
> 
> Just want to double confirm with you.
> 
> Thanks,
> Qian
(In reply to Qian Guo from comment #18)
> Hi, Marcelo
> 
> Do you mean that no need test the windows guest(it need windows qemu-ga
> driver) for this bug, since just Linux guest can pass this bug ?
> 
> Just want to double confirm with you.
> 
> Thanks,
> Qian

Qian,

Correct.

(In reply to Marcelo Tosatti from comment #19)
> (In reply to Qian Guo from comment #18)
> > Hi, Marcelo
> > 
> > Do you mean that no need test the windows guest(it need windows qemu-ga
> > driver) for this bug, since just Linux guest can pass this bug ?
> > 
> > Just want to double confirm with you.
> > 
> > Thanks,
> > Qian
> (In reply to Qian Guo from comment #18)
> > Hi, Marcelo
> > 
> > Do you mean that no need test the windows guest(it need windows qemu-ga
> > driver) for this bug, since just Linux guest can pass this bug ?
> > 
> > Just want to double confirm with you.
> > 
> > Thanks,
> > Qian
> 
> Qian,
> 
> Correct.

Thanks, and according to this comment, I will set this bug as verified

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://rhn.redhat.com/errata/RHBA-2015-1275.html