Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 520417

Summary: Don't run hwclock on guests running kvmclock
Product: Red Hat Enterprise Linux 5 Reporter: Glauber Costa <gcosta>
Component: ktuneAssignee: Thomas Woerner <twoerner>
Status: CLOSED WONTFIX QA Contact: BaseOS QE <qe-baseos-auto>
Severity: medium Docs Contact:
Priority: low    
Version: 5.4CC: pknirsch, tburke
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: 2009-12-06 10:34:11 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:
Bug Depends On: 519771    
Bug Blocks:    

Description Glauber Costa 2009-08-31 12:12:08 UTC 
In the spirit of #518039, I think we should provide users with a script that disables invocation of hwclock at boot time, when we are running kvmclock.

The problem that it fixes has been reported for Fedora in #512376.

To summarize, all tricks done by hwclock are quite expensive. It means that by the time hwclock sets guest time, one or two seconds (sometimes even three) has already elapsed, and users will then see time in guest always behind (although with a constant delta, because of kvmclock). This leads to the need of an unnecessary ntp invocation on the guest to keep the time in sync.

The simple solution is, upon finding we're running kvmclock, do an mv /sbin/hwclock to /sbin/hwclock.old, or something like that. A reversal script can also be provided if we feel like it.

Note that this will not work on x86_64 until #519771 is fixed (it's in POST state)