Description of problem: Version-Release number of selected component (if applicable): Host info # uname -r 2.6.18-260.el5 [root@t1 ~]# rpm -q kmv package kmv is not installed [root@t1 ~]# rpm -q kvm kvm-83-232.el5 Guest info: # uname -r 2.6.18-261.el5 How reproducible: 2/2 Steps to Reproduce: 1.sync host's clock with ntpserver 2.start VM /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 Actual results: after step5, # ntpdate -q clock.redhat.com server 66.187.233.4, stratum 1, offset 3443.028276, delay 0.31119 17 May 02:04:43 ntpdate[3474]: step time server 66.187.233.4 offset 3443.028276 sec Expected results: time drift should less than 5 secs Additional info: 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.