Bug 624572 - time drift after guest running for more than 12 hours
Summary: time drift after guest running for more than 12 hours
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: beta
: 6.1
Assignee: Zachary Amsden
QA Contact: Virtualization Bugs
Keywords: Reopened, RHELNAK
Depends On:
Blocks: Rhel6KvmTier1
TreeView+ depends on / blocked
Reported: 2010-08-17 02:24 UTC by Shirley Zhou
Modified: 2015-03-05 00:52 UTC (History)
8 users (show)

Clone Of:
Last Closed: 2011-04-07 16:59:01 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0534 normal SHIPPED_LIVE Important: qemu-kvm security, bug fix, and enhancement update 2011-05-19 11:20:36 UTC

Description Shirley Zhou 2010-08-17 02:24:57 UTC
Description of problem:
time drift after guest running for more than 12 hours

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.sync time on host
ntpdate -b clock.redhat.com
2.run rhel6 guest with time option as :
-rtc base=utc,clock=host,driftfix=slew 
3.do sync time on guest
ntpdate -b clock.redhat.com
4.query time on guest
ntpdate -q clock.redhat.com
offset is -0.299896
5.running this guest for 14 hours,then query time again
ntpdate -q clock.redhat.com
server, stratum 1, offset -9.975898, delay 0.34035
17 Aug 09:44:46 ntpdate[4619]: step time server offset -9.975898 sec

Actual results:
After guest run a long time, clock drift have huge increase.

Expected results:
There should not be huge increase time drift after guest running long time.

Additional info:

Comment 2 RHEL Product and Program Management 2010-08-17 02:58:39 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 3 Dor Laor 2010-11-21 22:34:26 UTC
Not sure that is that bad but worth investigation.

Comment 4 Zachary Amsden 2011-03-29 18:35:06 UTC
This bug is really old and fixes have gone in to the kvmclock and TSC code since.  Suggest we re-test to verify the bug still exists.

Comment 10 Zachary Amsden 2011-03-30 22:05:38 UTC
I don't have access to Bug 682613, was this last update posted in the wrong bug?

Comment 12 Dor Laor 2011-03-31 11:18:23 UTC
*** Bug 682613 has been marked as a duplicate of this bug. ***

Comment 13 Zachary Amsden 2011-03-31 19:26:03 UTC
So... as for the duplicate, same comment applies.

Host clock drifting is not a virt bug... we can't stop guest clocks drifting
when the host isn't even stable.  Re-assigning component to kernel.

If the host clock drift isn't a regression, it's possible this is just a
drifting or unstable host.  It's also possible the NTP server measurement is
being affected by network latency.  These are rather difficult things to rule
out, but the first step would be to see if the drift still exists with a 6.0
kernel on the same host.

This bug is kind of a mess.  I suggest we re-test to make sure it's really a bug.  Also, the attachment showing the drift results were attached to the other bug.

I'm going to close THIS bug as a duplicate and re-open the other one which is under the proper component.

*** This bug has been marked as a duplicate of bug 682613 ***

Comment 14 Zachary Amsden 2011-03-31 19:36:16 UTC
Okay, pending further investigation, I am re-opening this bug.

PLEASE DO NOT CLOSE EITHER OF THIS OR 682613 as duplicates.  There are two separate issues being reported.

One is a very small drift reported on a system which apparently has a drifting host clock (682613).  Not sure this is a real bug or can even be fixed.  That bug is not a virt issue, but a kernel issue.

This bug (624572) report concerns a virt guest running for over 14 hours having a "huge" drift, -9.9 seconds.  Quantitatively, that is a 200 part per million error, which isn't actually huge, and is within the threshold of NTP correctable error.

Can we please also verify whether or not the host clock is drifting on the same machine for which this bug was reported?

If that does indeed turn out to be the case, then we can dismiss one of these as duplicates, but for now with the absence of any known drift on the host clock, we still cannot rule out a virt bug on this one.

Can we also double check which clocksource was being used in the guest here?  Kvmclock or something else?



Comment 15 Zachary Amsden 2011-04-05 21:55:48 UTC
Need to very if this is indeed a drifting host or something else.

Comment 16 Mike Cao 2011-04-07 03:06:48 UTC
Tried on kernel-2.6.32-128.el6.

1. running a guest on it 
2. load the host cpu
3. check the time drift after 12 hours

Actual Results:
ON AMD host : 
after 14 hours ,time drifted 6.6 sec
ON intel host:
after 13 hours ,time drifted 0.3 sec

Comment 17 Zachary Amsden 2011-04-07 16:59:01 UTC
6.6 seconds in 14 hours is less that 140ppm error, which is within hardware expectation and within NTP adjustable tolerance of 500 ppm.

Differing drift on AMD and Intel platforms confirms it is a platform clock stability issue and not a systemic kernel or virtualization problem, so I'm closing the bug.

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