Reading this: What are the limits of running NTP servers in virtual machines? (2010)

And this: https://github.com/geerlingguy/ansible-role-ntp

I'm not sure what exactly I'm installing. Especially if I'm installing inside a VM.

I'm reading that VMs can synchronise their clock from their host system... but I've never heard of this before, and don't know where I could find the configuration for that. My personal experience is only with VirtualBox.

If I install NTP on a virtual machine server, let's say an Ubuntu server, as far as I'm aware, I'm only installing a tool that will be able to synchronise with external NTP servers in order to keep its time drift from going too far.

Is that what's happening, or is more happening? Am I installing an NTP server that then... nobody is synchronising up to? Because all the VMs would just have it installed and no VMs would then ever be configured to look at a specific server.

If all I want is to:

  1. Set the time zone
  2. Set things up so that time drift is minimized
  3. On a virtual machine or a physical machine

What do I need to know and what do I need to do?

Because in the past I just installed NTP on VMs running in VirtualBox/Proxmox/VMware and that's run fine for years. I recall many occasions of checking the time on various VMs, and never once encountering a situation where what I saw on the VM didn't make sense when looking to my local clock.

  • Short answer: Only if you're installing an NTP server. If you're installing an NTP client, then no, you're (probably) not installing a server. If someone says "I'm installing NTP" it is unclear whenther they mean NTP server or NTP client.
    – Chris Dodd
    Apr 11 at 4:03
  • 1
    NTP is a little oddball in that the specification doesn't distinguish between servers and clients. The program you use to sync from another computer is the same program that allows other computers to sync from yours. Of course, if you want to prevent them from doing that, there is an option to block it.
    – user253751
    Apr 11 at 4:13

1 Answer 1


Short answer: Usually, if you're installing an NTP daemon, you're installing the capability to both sync the local clock, and to provide time to clients over the network. However, there are some subtleties with this, and you've asked a few more things that I'll try to answer as well.

(The information below assumes that the VM guests are Linux-based; the same advice may not apply to Windows guests.)

  1. Firstly, the question you linked to and all of the answers to it are just plain wrong today. It was asked 13 years ago and the most recent answer is 10 years old. Per my answer here, modern VM solutions have improved their capabilities considerably during that time, and VMs are usually perfectly acceptable NTP clients and servers, achieving sub 1 millisecond accuracy on average hardware. (My advice is to downvote that question and all of the answers saying that time sync in VMs doesn't work, but that probably won't stop it from showing up in search results, unfortunately. I'll probably write up a new answer to that question after I'm done here.) If you want to know more about the myth of broken time sync in VMs, check out my blog post.
  2. VMs can indeed sync their clock with their host system via hypervisor-specific mechanisms, and this was originally provided because time sync in VMs was poor. However, it is no longer necessary, and will generally achieve poorer results than using NTP. On VMware and Hyper-V this function should be turned off; I believe it is not provided (at least by default) on KVM and Xen; I'm not sure about VirtualBox.
  3. If you install NTP on a VM server, let's say an Ubuntu server providing the KVM hypervisor, you're syncing that server's clock with external sources (provided that they are reachable). You should include at least 4 remote sources, which is the default if you install chrony or ntp, and by installing one of those packages, you're keeping that host's system time disciplined by continuous correction against those external sources.
  4. Your VMs will use their host's system time as the seed for their system time, but because they run their own separate kernels they also have their own separate (virtualised) system clocks, which must also be disciplined.
  5. The timezone is completely independent from your time sync service. The kernel and NTP use UTC; time zones are a user space problem.
  6. By default, Ubuntu does not use either chrony or ntp but systemd-timesyncd, which is an SNTP client only and is not capable of being an NTP server. By default chrony ignores all network requests and therefore acts only as an NTP client, but can be configured as a server with a short directive (see below). The default configuration of ntp is slightly different and will allow remote clients to sync time over the network, but not to query any server details.

So to sum it up, a reasonable setup for a standalone VM server and the VMs running on it might be for all of them to use the NTP pool individually, and for the VMs to use the host as an additional time source. If the host is tracking the pool sources well, then most of the clients will probably sync with the server most of the time (because of the low network delay in reaching it), but will have the pool servers as a quality check on the host NTP service.

Assuming Ubuntu and chrony, the server's config could start with the default:

# Default chrony.conf on Ubuntu, sans comments and blank lines
confdir /etc/chrony/conf.d
pool ntp.ubuntu.com        iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1
pool 2.ubuntu.pool.ntp.org iburst maxsources 2
sourcedir /run/chrony-dhcp
sourcedir /etc/chrony/sources.d
keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
ntsdumpdir /var/lib/chrony
logdir /var/log/chrony
maxupdateskew 100.0
makestep 1 3
leapsectz right/UTC

And then add these lines to allow guests from the local subnet, assuming that it uses and 2001:db8:0:2::/64 as its IPv4 and IPv6 addresses:

allow 2001:db8:0:2::/64

Similarly, a VM would start with the same default configuration and add this line to include the server as a source, assuming the server is resolvable by DNS as vmhost.local:

server vmhost.local iburst

Or if you provide NTP servers in your local DHCP server, your VMs using chrony should automatically pick that up, given the default configuration.

  • 2
    VMs can indeed sync their clock with their host system via hypervisor-specific mechanisms, and this was originally provided because time sync in VMs was poor. You may be overstating the "NTP in VM goodnow" assertion. Going back at least to 2008, official recommendation from Microsoft was to use either NTP or synchronize with AD. Hardware time synchronization has not worked reliably on hypervisor or hardware platforms, and turning off hardware synchronization and switching to another source has been a persistent problem forever on Windows at least.
    – Greg Askew
    Apr 10 at 11:55
  • Ok, I'm gonna read this. Here I go.
    – KoenDG
    Apr 10 at 20:08
  • 1
    Point 1 seems like the curse of SEO. It's old and now it's on top of the search results. For me anyway.
    – KoenDG
    Apr 10 at 20:09
  • 2
    "Going back at least to 2008" - man, 2008 is so old it is reaching drinking age. This was indeed fixed IN WINDOWS SERVER 2016. Which, already, is 8 years old and a little behind - 2 commercial releases actually.
    – TomTom
    Apr 10 at 20:43
  • 2
    @KoenDG: If you install chrony or ntp on Ubuntu, it will automatically remove systemd-timesyncd.
    – Paul Gear
    Apr 11 at 2:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .