Running Chrony NTP under a VMware Guest

Here’s a quick guide to run an NTP (Network Time Protocol) server using Chrony with a GPS (optional) receiver on a VMware ESXi Guest running Ubuntu 18.04. I should note this is experimental and something I setup in my homelab temporarily. For production environments I would run NTP on physical hardware and not VMware.

Create and Configure VM

Be sure to disable Guest Tools Time synchronization by editing the VM settings and uncheck Synchronize guest time with host.

Set the CPU shares to High… we want the NTP server to have priority if there is processor contention.

Install Chrony

Shell

1

2

sudo apt install chrony

sudo vim/etc/chrony/chrony.conf

/etc/chrony/chrony.conf

Shell

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

# Welcome to the chrony configuration file. See chrony.conf(5) for more

# information about usuable directives.

# This will use (up to):

# 3 sources from ntp.ubuntu.com

# 3 sources from us.pool.ntp.org

# 3 sources from time.nist.gov

pool ntp.ubuntu.comiburst maxsources3

pool us.pool.ntp.orgiburst maxsources3

pool time.nist.goviburst maxsources3

# This directive specify the location of the file containing ID/key pairs for

# NTP authentication.

keyfile/etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate

# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.

rtcsync

# Step the system clock instead of slewing it if the adjustment is larger than

# one second

makestep1-1

allow

I diversified between Ubuntu’s, NTP.org’s and NIST’s time server pools.

That’s it, after restarting the chrony service (service restart chrony) you should be able to get time reports by running:

Shell

1

2

3

chronyc sources-v

chronyc sourcestats-v

chronyc tracking-v

Why You Shouldn’t Run an NTP Server in a VM Guest

VM’s can’t keep accurate time

I’ve generally found that VMs keep great time inside of VMware. One thing that can help with this is setting the CPU shares to high so your time server always has a priority. I ran Chrony in a VM for several weeks, compared it with Chrony on a Raspberry Pi. Both were acceptable, and both had a smaller standard deviation than public NTP servers over the internet, but the VM had a much smaller standard deviation than the Pi. That tells me VMs running on better hardware may be better than lesser bare physical hardware at time tracking under certain conditions, and a local NTP server in a VM can be more precise than grabbing time off the internet.

VMs can become out of sync during snapshots, suspend, failover, etc.

I ran a suspend test and this is true. I paused a VM, waited 10 seconds, then resumed it. It reported the wrong time to NTP clients for several minutes before it corrected itself from external NTP servers. Here’s a screenshot of my NTP server being 11 seconds off after a pause!

This is a valid reason to run an NTP server on physical hardware. However, I think it is possible to run an NTP server under VMware with the following precautions:

Your NTP servers under VMware should never be paused. That means they should be excluded from failover (instead of failover it’s better to configure multiple NTP servers for your clients to connect to since it’s better for an NTP server to be down than report a wrong time).

Have multiple NTP servers. At least three. You’ll notice in the screenshot above Chrony (running on a separate physical machine) flagged the server as not being accurate. This way if one of your VMs gets paused chrony will switch to another time-source automatically.

Set makestep 1 -1 in the chrony.conf file (this tell chrony that any difference greater than one second will get stepped which allows for faster correction after a resume).

GPS Receiver

This is not really related to VMware. But I had a GPS receiver so thought I’d see how it works with Chrony….

I have a GlobalSat BU-353S4 USB GPS Receiver. This isn’t the best GPS receiver for accuracy. For me it’s accurate to within a few hundred milliseconds which is good enough for my experimental purposes but worse than just grabbing time off the internet. For serious time-keepers you’ll be wanting to use something faster than USB and more accurate than what a cheap GPS receiver can provide.

Configure gpsd

Shell

1

2

sudo apt install gpsd gpsd-clients

sudo vim/etc/default/gpsd

/etc/default/gpsd

Shell

1

2

3

4

5

6

7

8

9

10

11

12

# Start the gpsd daemon automatically at boot time

START_DAEMON="true"

# Use USB hotplugging to add new USB devices automatically to the daemon

USBAUTO="true"

# Devices gpsd should collect to at boot time.

# They need to be read/writeable, either by user gpsd or the group dialout.

DEVICES="/dev/ttyUSB0"

# Other options you want to pass to gpsd

GPSD_OPTIONS="-n -F /var/run/gpsd.sock"

Install Chrony

1

2

sudo apt install chrony

sudo vim/etc/chrony/chrony.conf

/etc/chrony/chrony.conf

Shell

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

# Welcome to the chrony configuration file. See chrony.conf(5) for more

# information about usuable directives.

# This will use (up to):

3sources from ntp.ubuntu.com

3sources from us.pool.ntp.org

3sources from time.nist.gov

1GPS device

pool ntp.ubuntu.comiburst maxsources3

pool us.pool.ntp.orgiburst maxsources3

pool time.nist.goviburst maxsources3

refclock SHM0refid GPS precision1e-1offset0.250delay1e-9

# This directive specify the location of the file containing ID/key pairs for

# NTP authentication.

keyfile/etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate

# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.

rtcsync

# Step the system clock instead of slewing it if the adjustment is larger than

# one second, at any time

makestep1-1

allow

So, how did I get the values on the refclock line…

The way I came up with my offset of 0.250 is by initially setting the offset to 0.0, restarting chrony, and running chronyc sources -v several times taking note of the offset. I’d get numbers like +249ms, +253ms, +250ms, etc.

Since my GPS is off by about 250ms I set the offset to 0.250. Now it’s usually not off by more than 100ms.

The 100ms+- variance is not a problem when being combined with other sources, but if it was the only time source I’d be better off tolerating drift than the high variance of GPS for a short period without access to the NTP pools, if I had no internet for several months or an air-gapped network then time via GPS would probably be better than nothing–but a better GPS receiver should be used in those scenarios.

For most networks running chrony in a VM and using a GPS is unnecessary. It’s better to keep it simple. I just use the NTP service on my pfSense router and set all the clients to that.

3 thoughts on “Running Chrony NTP under a VMware Guest”

Cool post, and a lot to think about – just off hand, how do you think it compares to a more conventional setup of using 2xWindows domain controllers as NTP servers, the first of which has a local NTP pool in its registry, and the second one pulling from the first?

Good question averyfreeman. I’m not that familiar with Windows domain controllers–I know the sysadmins where I worked awhile ago stopped using Windows DCs (running on bare metal) as the main time source because they’d drift ahead or behind actual time by a minute or two throughout the day. I don’t know if that was an issue with the Windows Time Service or an issue in our environment (could have been bad hardware that couldn’t keep good time).

. <-- this is a dot

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 158 other subscribers

Email Address

b3n.org is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to amazon.com