On Mon, Jun 23, 2014 at 9:54 AM, David Woolley <david@ex.djwhome.demon.invalid> wrote: > On 23/06/14 13:12, Miroslav Lichvar wrote: >> >> I think it all depends on the VM implementation > > It will still be subject to potentially large scheduling delays between NTP > packet arrival and processing. Also, unless you restrict VM to a single > host, the TSC could jump
The OP said "Why are NTP Servers running on virtualized hardware (vmware) unsuitable to serve time to clients?" but referred to a generalized recommendation. I'm sure the recommendation is intended for a "generic" virtual environment not the commercial product VMWare. I don't know about VMWare specific capabilities but the systems I'm familiar with either: 1) have one clock with a fixed offset allowed for domains. 2) have a vm clock that's a reasonable copy of the host clock which can appear to be changed but isn't. 3) have a vm clock that is read-only (attempts to write return insufficient privilege). All of which make running a clock-disciplining system fruitless. I wondered about this when reading "$40/mo in Bandwidth" for a pool server. I suppose long T deviation could provide insight in clock quality. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
