-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
-----END PGP SIGNATURE-----
On Mon, 09 Dec 2013 12:13:22 -0600
Chris J Arges <firstname.lastname@example.org> wrote:
> On 12/09/2013 11:50 AM, Serge Hallyn wrote:
> > Chris Arges (cc:d) has looked into this before in-depth. But I
> > don't seem to have the email with his conclusions. Chris, could
> > you summarize here what you had found when you looked into our
> > previous suggestion to not enable ntp in guests?
> Here is the original thread about this topic:
> Originally we had recommended _not_ to use NTP on VMs, but after
> researching this a bit further it seemed clear that NTP should work
> perfectly fine. The modification I made is updated here:
> My statement was pretty vague on purpose.
> If you are doing lightweight stuff when you boot the VM the kvmclock
> will setup the clocksource just fine and we expect the system time to
> not drift too much while the VM is up.
> For heavy duty stuff where you have many VMs, they run for a long
> time , or never shutdown/reboot the machine, it makes sense to setup
> NTP client on the VM using the host machine as the ntp server.
I would like to point out that my original email -- and the start of
this thread -- was not fixed on having NTP running on VMs in
particular, but *servers* generically.
So, I guess, we *should*:
* be running NTP on bare-metal servers;
* be running NTP on VMs, set to sync with the host.
Of course, this is a simplification: on a complex environment, a single
source for time sync should be selected for *all* bare-metals. Which
one, if a stratum 1 or 2 (or even lower) is not a problem -- as long as
all the machines are syncing to the same time provider.
But, on a default install, using the *.ntp.ubuntu.com providers, we
would have this, even if all the bare-metals directly sync to
*.ntp.ubuntu.com (but this is would not be ideal).
ab alio expectes alteri quod feceris