I'm seeing all sort of documentation about how it's not a great idea to use a
VM as an NTP server due to how sketchy time tracking is within a VM.
My supervisor directed me to try it anyway. He feels that our existing NTP
servers are too old and need to be replaced, and he wants to replace them
My experience is thus:
The misbehavior of NTP on a VM will happen "when you care most". When
the host is under resource constraints, clock cycles will be stolen from
some guests so that other more demanding guests can have them.
D
On 4/4/2016 12:18 PM, Jeremy Charles wrote:
>
> I’m seeing all so
NTP as a client on VMs is sketchy at best. Make sure you follow the
documentation from both your hypervisor and OS vendors in order to get it to
behave as well as possible. I doubt I would trust a VM as an actual NTP
server, but it also likely depends on the sensitivity of the devices utilizin
We're running VMs as NTP servers in several places, and our
experience has been that it works fine under normal circumstances, but
things get out of sync (at least temporarily) when a vMotion operation
occurs.
I haven't had time to do any significant research into this, but have
conside
On Mon, Apr 04, 2016 at 04:18:35PM +, Jeremy Charles wrote:
> I'm seeing all sort of documentation about how it's not a great idea to use a
> VM as an NTP server due to how sketchy time tracking is within a VM.
>
> My supervisor directed me to try it anyway. He feels that our existing NTP
>
I've found Raspberry PI's to be OK for small-scale NTP servers, if not
doing much else. The clocks aren't fantastic, but they track higher level
stratum clocks quite well in my very limited experience.
Hmmm, the screenly folks do a turnkey SD card image for PIs for their app.
I wonder if it would
You could consider an appliance approach...
on the cheap side:
http://www.bswusa.com/Site-Control-Broadcast-Tools-NTP-Server-Sentinel-P8700.aspx?gclid=Cj0KEQjwoYi4BRDF_PHHu6rI7NMBEiQAKZ-JuLzp0zvvbEe8pxNHVIExueJFtjUYir1BjggIv6B-rIEaAs_W8P8HAQ
On te more expensive side:
http://www.endruntechnolog
On Mon, Apr 04, 2016 at 11:15:37AM -0700, Tom Perrine wrote:
> I've found Raspberry PI's to be OK for small-scale NTP servers, if not
> doing much else. The clocks aren't fantastic, but they track higher level
> stratum clocks quite well in my very limited experience.
>
> Hmmm, the screenly folks
Tom> I've found Raspberry PI's to be OK for small-scale NTP servers,
Tom> if not doing much else. The clocks aren't fantastic, but they
Tom> track higher level stratum clocks quite well in my very limited
Tom> experience.
Tom> Hmmm, the screenly folks do a turnkey SD card image for PIs for
Tom> t
On 04/04/16 09:18, Jeremy Charles wrote:
> I’m seeing all sort of documentation about how it’s not a great idea to
> use a VM as an NTP server due to how sketchy time tracking is within a VM.
>
> My supervisor directed me to try it anyway. He feels that our existing
> NTP servers are too old an
To be totally fair if you are to the point of considering putting your
NTP server in a VM it may be worth seeing if you even actually need one.
If its going to run well in a VM the public stratum servers are going to
work for what you need, if its not you're just going to be buying
hardware in 6 mo
Are your NTP servers just pulling from upstream time servers and serving to
your fleet? If so, and given that you're only running 2 physical servers
(should be 3, 5 or 7 depending on the writeup you read...), that will be fine
as long as you do follow your hypervisor's best practices for NTP se
> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org]
> On Behalf Of Chris Snell
>
> Certain protocols/software fail badly as soon as time is
> out
> of sync even a few milliseconds (*cough* AD clients *cough*).
AD's tolerance is +/- 5 minutes by default.
> On Apr 4, 2016, at 13:57, Dan Ritter wrote:
>
> On Mon, Apr 04, 2016 at 04:18:35PM +, Jeremy Charles wrote:
>> I'm seeing all sort of documentation about how it's not a great idea to use
>> a VM as an NTP server due to how sketchy time tracking is within a VM.
>>
>> My supervisor directe
> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org]
> On Behalf Of Dan Ritter
>
> Note that NTP is an extremely easy task in most situations, and
> dedicating two 1U boxes for general infrastructure (DNS, DHCP,
> NTP, possibly TFTP for PXE) should be an easy sell in most
> c
Time syncing is one of the biggest problems VMs have. Unless you're able
to fully understand the NTP source code and and all of the intricacies of
clock syncing, you really aren't qualified to evaluate it. "I don't see
any issues", especially in the face of pretty much every Internet resource
tel
To clarify… I’m of the strong opinion that using VMs as NTP servers is a bad
idea. My supervisor is electing to disregard the overwhelming documentation
that it’s a bad idea. He’s also disregarding his own lack of qualification for
evaluating the issues at hand. He said, “Well, try it and se
On Mon, Apr 04, 2016 at 07:42:10PM +, Jeremy Charles wrote:
> Based on earlier feedback from this group, I???ve sent him a potential
> workaround of sticking an NTP server VM on each of four or more physical VM
> hosts. The idea is that if one or two physical hosts get busy, the NTP
> clien
gt; Tech@lists.lopsa.org <mailto:Tech@lists.lopsa.org>
>> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
>> <https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech>
>> This list provided by the League of Professional System Administrators
>> http://l
Hello Jeremy
Admittedly, I don't know much about NTP other than it's purpose and some of
its abilities.
Without wanting to hijack this thread, I'm curious - are all of your NTP
clients, VMs themselves? If VMs are so bad at tracking time, then what
good are they for any reason? If an NTP client
If you use an unstable time source, the clients will detect it and deem
the server unsuitable (marked as a false ticker.)
At that point all your clients drift on their own.
So, ya, it is important the the servers be stable. The clients can be a
bit unstable and the ntpd on them will fight the
21 matches
Mail list logo
