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:


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.