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.)
- 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.
- 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.
- 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.
- 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.
- The timezone is completely independent from your time sync service. The kernel and NTP use UTC; time zones are a user space problem.
- 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
rtcsync
makestep 1 3
leapsectz right/UTC
And then add these lines to allow guests from the local subnet, assuming that it uses 192.0.2.0/24 and 2001:db8:0:2::/64 as its IPv4 and IPv6 addresses:
allow 192.0.2.0/24
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.
