No one wants to pay for insurance.
Running a dozen Chrony or NTP servers in VMware for a month does not equate
to: "Hey look, if I don't pay for auto insurance for 30 days, everything is
fine; let's cancel all of our policies on the fleet of trucks".
If you only have to worry about Kerberos in yo
TL;DR: Here be nitpicks maquerading as answers, humor
in wisdom's drag.
On 2016-04-05 12:47, Edward Ned Harvey (lopser) wrote:
> It's clear that the industry best practice is to use a real
> time source, but there is a flip side: If you deviate from the
> industry best practice, how much d
Weather or not you end up running NTP using a VM is up to your site.
I would want to know if your monitoring system detects when your NTP time
drifts though.
If your time does drift, monitoring alerts happen, you investigate. If it
turns out to be a VM drift issue you then have evidence for yo
> It's clear that the industry best practice is to use a real time source, but
> there is a flip side: If you deviate from the industry best practice, how
> much do you risk? When instructed to deviate from best practice, should you
> be upset and insist that your boss put the request in writing
It's clear that the industry best practice is to use a real time source, but
there is a flip side: If you deviate from the industry best practice, how much
do you risk? When instructed to deviate from best practice, should you be upset
and insist that your boss put the request in writing, creati
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
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
ew Butch)
>4. Re: VM as an NTP server (Edward Ned Harvey (lopser))
>5. Re: VM as an NTP server (Brian Mathis)
>
>
> --
>
> Message: 1
> Date: Mon, 4 Apr 2016 13:05:52 -0500
> From: Mike Robinson
&g
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
Sent: Monday, April 4, 2016 2:29 PM
To: Jeremy Charles
Cc: tech@lists.lopsa.org
Subject: Re: [lopsa-tech] VM as an NTP server
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
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
> 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
> 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 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.
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
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
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
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 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
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
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
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
>
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
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
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
25 matches
Mail list logo
