[ntp:questions] R: Re: debugging strange ntp in virtual environment

Horvath Bob-BHORVAT1 Bob.Horvath at motorolasolutions.com
Thu Sep 19 15:48:21 UTC 2013



> -----Original Message-----
> From: questions-bounces+bob.horvath=motorolasolutions.com at lists.ntp.org
> [mailto:questions-bounces+bob.horvath=motorolasolutions.com at lists.ntp.org] On
> Behalf Of Rob
> Sent: Thursday, September 19, 2013 4:27 AM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] R: Re: debugging strange ntp in virtual
> environment
> 
> Riccardo Castellani <ric.castellani at alice.it> wrote:
> > I converted physical machine to virtual one, where there is NTPd service.
> > My
> > ESX host is running several guest OS included this NTP server.
> > Can it be this
> > one the problem ? Virtualization ? I'd like to know if ntpd adjusts
> > only OS time or it adjust hardware clock too.
> > In latter case if it adjusted hardwrae clock it shuld modify hardware
> > clock directly on ESX server (where there are running 0 virtual
> > machine)  ?!
> 
> Please read the knowledge base article on the VMware site for a full
> explanation of how it works and what you can configure.

I think the confusing aspect to many is that the recommendations from VMware are to run NTP on the guests to get time from an accurate time source, but not how to provide accurate time to VMs. 

I think the OP is saying that what they used as their stratum "x" time source just got virtualized.  So what works then? 

1) Having the guests pointed to where the newly virtualized ntp server points now?  
2) Having ntpd running somewhere on real iron.

For 1), the reason they may have had a stratum "x" server in the first place is because they can't directly use or don't want to hammer the "x-1" server. 

For 2), they just virtualized what used to be bare iron.  Their only option left is to put it on the ESXi bare iron. 

If running on bare iron on ESXi, then you have the following choice...

2a) let ESXi set the HW clock, and don't run ntp clients in the VMs
2b) turn off time synch at the ESXi layer and run ntp clients in the VMs to known good time sources
2c) run ntpd in the ESXi layer as both a client and server, and let the VMs get time from the ESXi instance of NTPi.

VMware's recommendation seems to be 2b. Turn off time synch in ESXI, and use ntp in the guests pointed at external time sources. 

If you don't have a good time source, or can't have all of our VMs accessing it, the next logical step is to try 2c). 

Part of the challenge we have had is that vSphere doesn't give you a lot of options.  You can go in and muck with the ntp.conf file directly, but then if someone touches the vSphere interface, it overwrites it.  

We also had a problem where the version of ntpd on the version of ESXi we are using is a couple of versions out of dates and has known problems (i.e. orphan mode increasing to infinity). Apparently we have had instances of ntpd silently failing in the ESXi layer. 

And of course, once you virtualize lots of machines onto a couple physical machines, you don't have many physical servers left to compare against each other (... a man with two physical servers is never quite sure...). 

If you can't do 2B, then 2C seem reasonable.  Back on 1/2B, I often get into arguments about overloading the time servers or the networks.  This is quite often overblown as many of the commercial time servers (and probably some not-so commercial ones too) can handle hundreds of thousands of clients.  The network bandwidth is also quite low give the size of the messages and the polling rates that things settle into (especially with NTPv4).  










More information about the questions mailing list