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

Rob nomail at example.com
Thu Sep 19 17:18:44 UTC 2013

Horvath Bob-BHORVAT1 <Bob.Horvath at motorolasolutions.com> wrote:
>> -----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 11:20 AM
>> To: questions at lists.ntp.org
>> Subject: Re: [ntp:questions] R: Re: debugging strange ntp in virtual
>> environment
>> Horvath Bob-BHORVAT1 <Bob.Horvath at motorolasolutions.com> wrote:
>> >
>> > 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.
>> Why?
>> What we have is a similar situation, we had a physical machine providing ntp
>> service to the network and we went to virtualisation.
>> The machine still providers good time.  It is still synchronized to time
>> sources on the network as it was before, and it still provides time to other
>> servers and clients on the local network.  Servers are other virtual servers
>> on the same ESX hosts.  Loading of the origin time servers is the same.
> Well, I thought what the OP and others have been saying is that they aren't getting good time running NTP as a server for other clients.  I suppose the definition of "good" may be the difference. 

No, they have errors in their configuration, and therefore their
server does not work correctly.
For example, they have configured the virtual server that they run their
NTP server on to lock its time to the host.  Then the offset cannot
decrease because the clock is not really controlled by ntpd, and ntpd
keeps telling it is unsynchronized.
That is an operator error, not a problem with the software.

> I have been running an experiment for several weeks now running several virtualized ntp servers and must admit I have been surprised they are running as well as they are. 

Yes, it works quite well.  I get offset and jitter well below a millisecond.

>> As we have two locations, we provide the DNS and NTP servers of the second
>> location as alternatives.  And hope they won't have to boot simultaneously.
> So, it sounds like you have two physical machines running VMs with ntpd as servers that are clients of known good external sources, and the "server VMs" are ntp clients of the "ntp VMs"? 

Yes.  More physical machines, but the idea is the same.  There are some VMs
that are NTP servers and are locked to eachother and to internet sources,
and all other VMs and the hosts are locked to that.

> If so, isn't the "man with two watches" a problem?  

No, there is no sync between the hosts and VMs within VMware (we have
configured that OFF, the default) so everything works as normal in NTP.

Only immediately after boot there are "problems" with relatively large
offsets of e.g. a second or more.  But we reboot not more than once a year.
(the hosts, that is)

More information about the questions mailing list