Bug 520653 - wallclock time does not survive reboots
Summary: wallclock time does not survive reboots
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm
Version: 5.4
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-01 16:07 UTC by Glauber Costa
Modified: 2018-02-14 22:18 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-14 22:18:18 UTC


Attachments (Terms of Use)

Description Glauber Costa 2009-09-01 16:07:53 UTC
If our guest does not have a stable time source such as kvm-clock, wallclock keeping won't survive reboots.

Take as an example a Fedora guest, running the jiffies clock source:

[root@virtlab1 kvm]# ssh root@192.168.55.3 date -u && date -u
Tue Sep  1 16:10:57 UTC 2009
Tue Sep  1 16:07:24 UTC 2009
[root@virtlab1 kvm]# ssh root@192.168.55.3 "init 6"
[root@virtlab1 kvm]# ssh root@192.168.55.3 date -u && date -u
Tue Sep  1 16:15:39 UTC 2009
Tue Sep  1 16:09:28 UTC 2009

Note that time has deviated.

The expected behaviour would be something in the lines of:

[root@virtlab1 kvm]# ssh root@192.168.55.3 date -u && date -u
Tue Sep  1 16:12:41 UTC 2009
Tue Sep  1 16:12:42 UTC 2009
[root@virtlab1 kvm]# ssh root@192.168.55.3 "init 6"
[root@virtlab1 kvm]# ssh root@192.168.55.3 date -u && date -u
Tue Sep  1 16:14:20 UTC 2009
Tue Sep  1 16:14:20 UTC 2009

Note that after a reboot, clocks are kept in sync.

Status:

Some dude just sent a patch for it upstream:

http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg00033.htm

If accepted, we should pick it up for RHEL.

Comment 1 Dor Laor 2009-10-29 22:18:28 UTC
Isn't it in already?

Comment 2 Glauber Costa 2009-10-30 08:38:24 UTC
Yes. I remember having sent a patch for it. But I might be wrong, or it might have been lost. Thanks for the reminder, I will look it up today

Comment 3 Glauber Costa 2009-10-30 09:38:03 UTC
Please disregard last comment, I might have been confused.

I was sure that my patch was upstream, but I turned out be wrong. It probably made into staging or next, but never reached master. (At least I can reach it via git log).

It seems Jan Kizka's "Enable host-clock-based RTC" was committed instead. It is a much larger patchset, and I will take a look on it as soon as possible

Comment 4 Dor Laor 2009-11-08 09:04:16 UTC
(In reply to comment #3)

> It seems Jan Kizka's "Enable host-clock-based RTC" was committed instead. It is
> a much larger patchset, and I will take a look on it as soon as possible  

Any news?

Comment 5 Glauber Costa 2009-11-09 13:05:26 UTC
I am not sure exactly why, but I can't reproduce this bug anymore.

I am moving to ON_QA

Comment 6 Miya Chen 2010-03-23 08:41:52 UTC
Hi, Glauber

This is what i found during testing with kvm-83-105.el5.4.28

guest : 32bitrhel5.5 
guest kernel : 2.6.18-194.el5
host cpuinfo:
processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 2
model name	: AMD Phenom(tm) 9600B Quad-Core Processor
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc pni cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy altmovcr8 abm sse4a misalignsse 3dnowprefetch osvw


steps:
1. start guest with jiffies clock source( append clock=jiffies to kernel line):
# /usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -smp 2 -m 2G -cpu qemu64,+sse2 -drive file=rhel5.5-32-virtio.qcow2,media=disk,if=virtio,boot=on -net nic,model=e1000,macaddr=20:20:20:25:22:33,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -vnc :10 -monitor stdio -no-kvm-pit-reinjection -M rhel5.4.4 -startdate now -notify all

2.check time in host:
# for i in `seq 1 2`; do ssh root@10.66.91.121 date -u ;date -u; echo ;sleep 10; done
Tue Mar 23 08:08:41 UTC 2010
Tue Mar 23 08:09:07 UTC 2010

Tue Mar 23 08:08:49 UTC 2010
Tue Mar 23 08:09:17 UTC 2010

3. reboot guest.
4. after reboot, check time in host:
# for i in `seq 1 2`; do ssh root@10.66.91.121 date -u ;date -u; echo ;sleep 10; done
Tue Mar 23 09:19:41 UTC 2010
Tue Mar 23 08:20:17 UTC 2010

Tue Mar 23 09:19:49 UTC 2010
Tue Mar 23 08:20:27 UTC 2010

Result:
guest has one hour jump

Comment 7 Glauber Costa 2010-03-23 15:12:35 UTC
Tried with most of your options, and can't reproduce that. Does it only happen with the jiffies clocksource? Or does it happen with other clocksources too ?


How long do you keep your guest running before rebooting it ?

Comment 8 Miya Chen 2010-03-26 09:01:42 UTC
Hi, Glauber

After changing host timezone from EDT to CST, problem of 1h jump disappear, not sure what's wrong, and I will follow it further.

Go back to the original problem, i tested it again using 32bitrhel5.5 guest with jiffies clock source:

cmd:
# /usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -smp 2 -m 2G -cpu qemu64,+sse2 -drive file=rhel5.5-32-virtio.qcow2,media=disk,if=virtio,boot=on -net nic,model=e1000,macaddr=20:20:20:25:22:33,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -vnc :10 -monitor stdio -no-kvm-pit-reinjection -M rhel5.4.4 -startdate now -notify all

1. check after boot:
# ssh root@guestip date -u ; date -u
Fri Mar 26 06:05:41 UTC 2010
Fri Mar 26 06:05:49 UTC 2010 

2. check after 20 mins:
# ssh root@guestip date -u ; date -u
Fri Mar 26 06:12:54 UTC 2010
Fri Mar 26 06:14:06 UTC 2010

3. check after reboot:
# ssh root@guestip date -u ; date -u
Fri Mar 26 06:16:11 UTC 2010
Fri Mar 26 06:17:42 UTC 2010

4. check after 3 hours:
# ssh root@guestip date -u ; date -u
Fri Mar 26 08:38:10 UTC 2010
Fri Mar 26 09:00:05 UTC 2010

Result:
Time drift between guest and host became larger and larger.
kvmclock does not have this problem.

Comment 9 Glauber Costa 2010-03-26 13:16:10 UTC
well, so it does not have anything to do with reboots, which was the original report, right? Time drifts even before you reboot.

Comment 10 Miya Chen 2010-03-29 04:31:01 UTC
(In reply to comment #9)
> well, so it does not have anything to do with reboots, which was the original
> report, right? Time drifts even before you reboot.    

yes, time drift before reboot.

Comment 11 juzhang 2011-07-18 12:00:40 UTC
> Result:
> Time drift between guest and host became larger and larger.
> kvmclock does not have this problem.
Hi,Dor

   Since our default kvmclock does not hit this problem,would you please close this issue as won't fix?I will downgrade severity to low first.

Comment 16 Qunfang Zhang 2014-08-11 08:01:22 UTC
Setting to VERIFIED since could not reproduce the issue on latest kvm version kvm-83-268.el5.

Comment 18 Jeff Nelson 2018-02-14 22:18:18 UTC
Closing this BZ as it has been sitting in VERIFIED for more than three years and the reported problem could not be reproduced. Please reopen if you believe this to be in error.


Note You need to log in before you can comment on or make changes to this bug.