Description of problem: I use Rhev-manager (sm81) to create a kvm guest. Before I shut down it, I first do time ynchronization with ntp server. Then shut down and booting it again. After booting, I check time synchronization again. Then I find that there is 8 second time drift in guest. But in host, there isn't any time drift. Version-Release number of selected component (if applicable): Rhev-manager (sm81) host: Rhev-hypervisor-5.5-2.2.6.1 kernel-2.6.18-194.11.1.el5 kvm-83-164.el5_5.21 guest: RHel 5.5 x86_64 kernel-2.6.18-214.el5 How reproducible: Awlays Steps to Reproduce: 1.Before shut down kvm guest, do time synchronization with ntp server [guest]#ntpdate 10.5.26.10 server 10.5.26.10, stratum 1, offset 0.000768, delay 0.29411 10 Sep 03:24:41 ntpdate[2661]: adjust time server 10.5.26.10 offset 0.000768 sec 2.Shut down kvm guest 3.Then boot it again 4.After booting, check time synchronization [guest]#ntpdate -q 10.5.26.10 server 10.5.26.10, stratum 1, offset 8.824427, delay 0.29636 10 Sep 03:32:38 ntpdate[2612]: step time server 10.5.26.10 offset 8.824427 sec Actual results: After step4, kvm guest will occur time drift 8s: Expected results: After step4, vkm guest's time will not time drfit. Additional info: The qemu command line used in rhev-hypervisor-5.5-2.2.6.1: usr/libexec/qemu-kvm -no-hpet -no-kvm-pit-reinjection -usbdevice tablet -rtc-td-hack -startdate 2010-09-10T10:08:35 -name rhel5_5_64 -smp 1,cores=1 -k en-us -m 512 -boot c -net nic,vlan=1,macaddr=00:1a:4a:42:41:0a,model=virtio -net tap,vlan=1,ifname=virtio_10_1,script=no -net nic,vlan=2,macaddr=00:1a:4a:42:41:67,model=virtio -net tap,vlan=2,ifname=virtio_10_2,script=no -drive file=/rhev/data-center/ca69b608-e64a-49f6-baa9-19eadaf339d8/08e9a1bd-e22a-45da-b9a2-4f2037e81b9b/images/1cdde3cf-9d97-45cd-ba4e-1b8e975e6cd1/d5778673-c40e-4cb5-8467-515cb67b094f,media=disk,if=virtio,cache=off,serial=cd-ba4e-1b8e975e6cd1,boot=on,format=raw,werror=stop -pidfile /var/vdsm/60c27f33-3dc1-4c39-9f7d-8b67555e3a3d.pid -vnc 0:10,password -incoming tcp::49158 -cpu qemu64,+sse2,+cx16,+ssse3 -M rhel5.5.0 -notify all -balloon none -smbios type=1,manufacturer=Red Hat,product=RHEV Hypervisor,version=5.5-2.2-6.1,serial=44454C4C-4200-104A-8048-B4C04F4D3258_00:22:19:c6:f6:12,uuid=60c27f33-3dc1-4c39-9f7d-8b67555e3a3d -vmchannel di:0200,unix:/var/vdsm/60c27f33-3dc1-4c39-9f7d-8b67555e3a3d.guest.socket,server -monitor unix:/var/vdsm/60c27f33-3dc1-4c39-9f7d-8b67555e3a3d.monitor.socket,server
Maybe a duplicate of bug #523478. What happens if you rename or delete /sbin/hwclock in the guest, so it is not run on boot?
Tested this bug on latest build,there is 1-2 seconds time drift after booting,following is the details: Host: rhel5.6 server Kernel: 2.6.18-241.el5 Kvm: kvm-83-224.el5 Guest: RHel 5.6 x86_64 kernel: 2.6.18-231.el5 Steps: 1.Start guest with CLI: /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu qemu64,+sse2 -drive file=RHEL-Server-5.6-64-virtio.raw,media=disk,if=virtio,boot=on,cache=none,werror=stop -net nic,model=virtio,vlan=0,macaddr=00:10:16:10:62:10 -net tap,vlan=0,script=/etc/qemu-ifup -uuid 14371d1a-d2b5-4fe9-a61c-ad25207673c6 -monitor stdio -vnc :1 -boot c -usbdevice tablet -no-hpet -rtc-td-hack -no-kvm-pit-reinjection -startdate now 2.Before shut down kvm guest, do time synchronization with ntp server for host and guest: [host]# ntpdate 10.5.26.10 31 Jan 03:12:03 ntpdate[6771]: adjust time server 10.5.26.10 offset 0.000907 sec [guest]# ntpdate 10.5.26.10 31 Jan 03:11:50 ntpdate[2304]: adjust time server 10.5.26.10 offset 0.000782 sec 2.Shut down kvm guest 3.Then boot it again 4.After booting, check time synchronization [guest]# ntpdate -q 10.5.26.10 server 10.5.26.10, stratum 1, offset 1.845853, delay 0.36089 31 Jan 03:15:40 ntpdate[2270]: step time server 10.5.26.10 offset 1.845853 sec resut: after booting, guest will have 1-2 seconds time drift.
The time sync with NTP server is only effective as long as the VM is up, and it is not saved anywhere for the next boot. On real hardware it would have been saved in the RTC (hardware clock that keeps counting when you turn off the machine) that is not emulated. Gleb, please confirm. Anyhow, closing since it is not high priority for RHEL5.8
(In reply to comment #6) > The time sync with NTP server is only effective as long as the VM is up, and it > is not saved anywhere for the next boot. On real hardware it would have been > saved in the RTC (hardware clock that keeps counting when you turn off the > machine) that is not emulated. > Gleb, please confirm. RTC part is irrelevant. Since the host is ntp synched the guest will get perfectly up-to-date time in RTC during boot. > Anyhow, closing since it is not high priority for RHEL5.8