Questions about KVM-Clock and NTP for Ubuntu Guests

Chris J Arges chris.j.arges at
Wed Apr 24 16:16:00 UTC 2013

Hash: SHA1

Hi everybody, I have a fairly in-depth set of questions about
kvm-clock and synchronization. I've tried to pare these down in to a
set of questions that may help clarify concerns of users that utilize
Ubuntu as a kvm guest. I've also done some (rough) experiments to
answer some of the basic questions.

My goal is for these to clarify [0] and be eventually update the wiki.

= Questions =

* Why precisely does Ubuntu recommend _not_ to use NTP in KVM guests [0]?
    Some distros and people [9][2][5] recommend using NTP in their
guests, as well as the KVM FAQ [1]. If kvm-clock accomplishes proper
clock synchronization, is NTP just a waste of time, or could it
actually cause bugs and additional problems? Would NTP fail because of
system time drift or other issues [5]?

* Does kvm-clock propagate the host system time to guests?
    Yes, it exposes the host system time as shown in the below
experiments. Does this also expose UTC corrections such as leap
seconds [5]?

* How can Guest VM's update their system time from hwclock?
   Executing "hwclock --hctosys" updates the system time, but perhaps
there is a better way?

* What happens when a system suspends and resumes?
   It looks like the system still maintains the proper timing.

= Experiment =

* Assuming you have a clean KVM guest setup.
  For my experiment I ran a 3.8.0-19 kernel in an raring amd64 server

* For each experiment record the following in the guest:
  dmesg | grep "setting system clock"
  echo "date +%s output = " $(date +%s)
  hwclock --debug | grep "Hw clock"
  clockdiff #or whatever the host machine IP is

* Compare to time when you start the vm and whenever you run the script.

1) Boot guest and record output, it should be somewhat close in time.
  * Host before boot: 1366742263
  [    0.528148] rtc_cmos 00:00: setting system clock to 2013-04-23
18:37:48 UTC (1366742268)

  * Host when executing script: 1366742312
  date +%s output = 1366742313
  Hw clock time : 2013/04/23 18:38:33 = 1366742313 seconds since 1969
  host= rtt=750(187)ms/0ms delta=-40ms/-40ms Tue Apr 23
13:38:33 2013

  So this matches expectations.

2) Change host system time and record output afterwards.
  * Host when executing script: 924374443
  date +%s output = 1366742454
  Hw clock time : 1999/04/17 18:40:44 = 924374444 seconds since 1969
  host= rtt=750(187)ms/0ms delta=-10513ms/-10513ms Tue
Apr 23 13:40:54 2013

  Looks like hwclock is correct, but 'date' doesn't reflect the
changed time.
  Running 'sudo hwclock --hctosys' fixes this:
  $ sudo hwclock --hctosys
  ubuntu at ubuntu:~$ echo "date output = " $(date +%s)
  date output =  924374611

2) Set host system time to something bogus, boot and check output.
  * Host before boot: 86415
  [    0.581315] rtc_cmos 00:00: setting system clock to 1970-01-02
00:00:20 UTC (86420)

  * Host when executing script:
  date +%s output = 1366742803
  Hw clock time : 1970/01/02 00:01:03 = 86463 seconds since 1969
  host= rtt=562(280)ms/0ms delta=18859219ms/18859219ms
Tue Apr 23 13:46:45 2013

  So again looks like hwclock is correct, but system time isn't
updated from hwclock on boot.

4) Boot machine and record data. Then suspend machine for X minutes,
resume and record data afterwards.
  Paused the VM for about 4m.
  ubuntu at ubuntu:~$ date +%s
  ubuntu at ubuntu:~$ date +%s
  This delta matches the pause of 4m, so the clock looks proper.

Below is a list of various references I looked at to help answer these
- --chris j arges

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the ubuntu-server mailing list