Red Hat Bugzilla – Bug 705254
Time drift on rhel5.7 guest when savevm/loadvm
Last modified: 2011-07-17 08:48:36 EDT
Description of problem:
Version-Release number of selected component (if applicable):
# uname -r
[root@t1 ~]# rpm -q kmv
package kmv is not installed
[root@t1 ~]# rpm -q kvm
# uname -r
Steps to Reproduce:
1.sync host's clock with ntpserver
/usr/libexec/qemu-kvm -M rhel5.6.0 -m 2G -smp 4,sockets=4,cores=1,threads=1 -name VM -uuid 02b8079c-cca0-ae65-c63a-a2aa4119497d -monitor stdio -no-kvm-pit-reinjection -rtc-td-hack -usbdevice tablet -startdate now -boot c -drive file=/home/rhel5_7_64.qcow2,if=virtio,format=qcow2,werror=stop,cache=none,boot=on -net nic,macaddr=54:52:40:33:4c:58,vlan=0,model=virtio -net tap -usb -vnc :1 -k en-us -balloon virtio -notify all -no-hpet
3.check clock drift in the guest
---->Actual Result of this step:no time drift
4.(qemu)savevm ,after that check clock drift of guest
---->Actual Result of this step: no time drift
5.(qemu)loadvm 1 ,after that check clock drift of guest
# ntpdate -q clock.redhat.com
server 184.108.40.206, stratum 1, offset 3443.028276, delay 0.31119
17 May 02:04:43 ntpdate: step time server 220.127.116.11 offset 3443.028276 sec
time drift should less than 5 secs
1.guest use kvm clocksource
2.Tried with clock=tsc in the guest ,hit the same issue.
3.Host use TSC clocksource
4.Not sure whether this one is same as Bug 703335, reported in case of missing bug.
Windows 2003R2sp2 64 bit guest hit the same issue .
This absolutely need to be investigated, it's not a RHEL 5.X bug, it's a problem with time keeping in the hypervisor instead - using KVM clock, guest time should stay caught up to real time.
Windows guests and TSC based timekeeping problems are interesting and possibly related, but most definitely not the same bug. Windows may not immediately catch back up to real time, and TSC based timekeeping may fail for a number of reasons to catch back up the real time.
This should remain open to track why guests using kvm-clock are not catching back up to real time immediately, which is supposed to be the advantage of KVM clock over other clocksources to begin with.
(In reply to comment #2)
> Windows 2003R2sp2 64 bit guest hit the same issue .
in comment #0 step4
for linux guest ,no time drift occurs
for windows guest ,time drift occures
So windows guest time drift related to guest (qemu)stop instead of (qemu)savevm
more info ,referring to Bug 705686
This is almost certainly a dup of 694398, although it may need to be tracked separately to get the fix into a different release.
There are other time-drift bugs, and this one saveVm+loadvm is not critical, nor it is reported by a customer, so I close it.