Bug 520653
| Summary: | wallclock time does not survive reboots | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Glauber Costa <gcosta> |
| Component: | kvm | Assignee: | Virtualization Maintenance <virt-maint> |
| Status: | CLOSED WORKSFORME | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.4 | CC: | bsettle, chayang, hhuang, jen, juzhang, lihuang, michen, qzhang, tburke, virt-maint |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-02-14 22:18:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Glauber Costa
2009-09-01 16:07:53 UTC
Isn't it in already? 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 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 (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? I am not sure exactly why, but I can't reproduce this bug anymore. I am moving to ON_QA 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.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.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 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 ? 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. well, so it does not have anything to do with reboots, which was the original report, right? Time drifts even before you reboot. (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. > 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.
Setting to VERIFIED since could not reproduce the issue on latest kvm version kvm-83-268.el5. 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. |