[ntp:questions] orphan mode, manycast, and virtualization

E-Mail Sent to this address will be added to the BlackLists Null at BlackList.Anitech-Systems.invalid
Mon Sep 9 22:38:19 UTC 2013

Horvath Bob-BHORVAT1 wrote:
> A) Run ntpd on the bare iron at the ESXi layer
>     and let it change the virtual hardware clock
>     (without ntpd running on VMs)
> B) Run ntpd on the bare iron at the ESXi layer
>     and let ntpd on the VMs use it as a time source
> C) Run ntpd on all the VMs and point them to as many "good"
>     ntp servers that you can find whether in its own ESXi
>     or another physical server's ntpd.

If your flavor can do A, it may be the best option;
 however IIRC, C may be the current recommendation
 {I haven't looked in several months}.


> One of the other constraints we have is sometimes we don't
>  have a good time source, and the requirement is that they
>  all be consistent, if not correct...
> Other times there is a good time source, but we have to
>  survive being unable to reach it...
> We are looking to take advantage of orphan mode but the
>  version of ESXi we are using has the version of ntpd that
>  has the orphan mode bug where the stratum starts climbing.


> One thought I had was using manycast to let the various servers,
>  physical and virtual, to find the best set of time sources
>  (again physical or virtual) they can find...

# e.g. ntp.conf for ALL your (Clients and/or Servers)
 keys "/etc/ntp.keys" # e.g. contains: 123 M LAN_MD5_KEY , 321 M Corp_MD5_KEY , ...
 trustedkey 123 321
 tos cohort 1 orphan 10
 restrict source nomodify
 manycastclient key 123 preempt
 multicastclient key 123 preempt
 pool pool.ntp.org preempt                # Won't hurt anything if the internet can't be reached

# Don't use server Undisciplined Local Clock (LOCAL)

E-Mail Sent to this address <BlackList at Anitech-Systems.com>
  will be added to the BlackLists.

More information about the questions mailing list