RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1379822 - Feature to update System Clock from kvm-clock in guests
Summary: Feature to update System Clock from kvm-clock in guests
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Marcelo Tosatti
QA Contact: Sitong Liu
Jiri Herrmann
URL:
Whiteboard:
Depends On:
Blocks: 1532529
TreeView+ depends on / blocked
 
Reported: 2016-09-27 18:27 UTC by John L Magee
Modified: 2018-04-16 17:56 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Release Note
Doc Text:
PTP device added to improve time synchronization of KVM guests The PTP device has been added for KVM guest virtual machines. It enhances the *kvmclocks* service by preventing clock divergence between the host and the guest due to NTP adjustment. As a result, the PTP device ensures more reliable time synchronization between the KVM host and its guests. For details on setting up the PTP device, see the Virtualization Deployment and Administration Guide.
Clone Of:
: 1532529 (view as bug list)
Environment:
Last Closed: 2018-01-05 21:21:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description John L Magee 2016-09-27 18:27:17 UTC 
Description of problem: unnecessary configuration and run time overhead required to run ntpd in all Linux Guests.

This is my assessment of the situation.

Bare Metal Linux Host Behavior

* The kernel reads the rtc (whatever hardware source is found) at boot to set System Time
* If ntpdate is enabled, it uses the specified (remote) server(s) to update the system and rtc time once.
* If ntpd or chronyd are enabled, they update rtc every 11 minutes (unless the 11 minute update is disabled or there is a bug or hwclock has been used in a fashion that disables it).
* There are conditions where the hardware clock is so different from the ntpdate/ntpd time, the kernel will not update the hardware clock (for example, this may be caused by a run down battery in a machine that has been powered off for a long time).

QEMU-KVM Linux Guest VM Behavior

* Kernel recognizes it is running in a kvm VM and sets clocksource to kvm-clock
* Kernel sets System Time from clocksource (same as bare metal)
* kvm-clock is kept in sync with the host hardware clock (sync’d on every dispatch as I understand it)
* If ntpd or chronyd are running, they keep the System Time up to date.  The Red Hat recommended configuration is to run ntpd on both the guest and the host. Other sources indicate it is not necessary or should not be run.
* However, without ntpd or chronyd, the System Time drifts back (loses time) from the initial setting (not sure how much or under what conditions).

Desired Linux Guest Optional Capability

In the situation where the Sys Admin can verify proper configuration and operation of the host time and clock management, provide a feature to allow the guest System Time to be updated from the kvm-clock. 

While the overhead of ntp on an individual guest may be very small, the combined load of several hundred guests on a host can add up to measurable overhead combining the guests and the host serving NTP to them.

Alternatively, at least acknowledge that running hwclock -s in a cron (perhaps every 11 minutes) is an acceptable replacement for running ntpd in this configuration.
Comment 2 Marcelo Tosatti 2017-07-18 22:06:27 UTC 
(In reply to John L Magee from comment #0)
> Description of problem: unnecessary configuration and run time overhead
> required to run ntpd in all Linux Guests.
> 
> This is my assessment of the situation.
> 
> Bare Metal Linux Host Behavior
> 
> * The kernel reads the rtc (whatever hardware source is found) at boot to
> set System Time
> * If ntpdate is enabled, it uses the specified (remote) server(s) to update
> the system and rtc time once.
> * If ntpd or chronyd are enabled, they update rtc every 11 minutes (unless
> the 11 minute update is disabled or there is a bug or hwclock has been used
> in a fashion that disables it).
> * There are conditions where the hardware clock is so different from the
> ntpdate/ntpd time, the kernel will not update the hardware clock (for
> example, this may be caused by a run down battery in a machine that has been
> powered off for a long time).
> 
> QEMU-KVM Linux Guest VM Behavior
> 
> * Kernel recognizes it is running in a kvm VM and sets clocksource to
> kvm-clock
> * Kernel sets System Time from clocksource (same as bare metal)
> * kvm-clock is kept in sync with the host hardware clock (sync’d on every
> dispatch as I understand it)
> * If ntpd or chronyd are running, they keep the System Time up to date.  The
> Red Hat recommended configuration is to run ntpd on both the guest and the
> host. Other sources indicate it is not necessary or should not be run.
> * However, without ntpd or chronyd, the System Time drifts back (loses time)
> from the initial setting (not sure how much or under what conditions).
> 
> Desired Linux Guest Optional Capability
> 
> In the situation where the Sys Admin can verify proper configuration and
> operation of the host time and clock management, provide a feature to allow
> the guest System Time to be updated from the kvm-clock.

Recently there has been a feature, called KVM-PTP, which exposes the host system
clock and allows chronyc in the guest to sync from the host system clock.

You should be able to sync the guest system clock using phc2sys.
Can you give that a try?

https://lwn.net/Articles/711613/

> 
> While the overhead of ntp on an individual guest may be very small, the
> combined load of several hundred guests on a host can add up to measurable
> overhead combining the guests and the host serving NTP to them.
> 
> Alternatively, at least acknowledge that running hwclock -s in a cron
> (perhaps every 11 minutes) is an acceptable replacement for running ntpd in
> this configuration.

It is not an acceptable replacement: if the guest clock is running faster than the host clock, hwclock -s will adjust the time backwards, which can cause application crashes. ntp and chrony take care of this.
Comment 3 John L Magee 2017-07-25 16:42:28 UTC 
I was finally able to test this on Fedora 26 with Chrony after finding this article https://opensource.com/article/17/6/timekeeping-linux-vms

support does not seem to be present in phc2sys or ptp4l or I couldn't figure out what options to use.

The chrony support seems to work very well

When might we expect it in RHEL 7? I see the ptp_kvm driver is in 7.4 but ther eis no mention of chrony support in the release notes.
Note You need to log in before you can comment on or make changes to this bug.