A while ago I experienced NTP synchronisation problems between Linux clients and the NTP server, a Windows 2003 server (Domain Controller role). As a temporary solution, a virtual machine was then set up which served as NTP server.
Due to virtualized hardware, the virtual machines often have problems with keeping up their (virtual) time. They often run too fast, are therefore in the future, sometimes they're lagging behind. So it was clear: To use a virtual NTP server must be a temporary solution.
After re-modifications and adaption of the Windows settings to be able to serve NTP requests, the Linux guests were switched back to re-use the physical NTP server.
But would it really make such a big difference? The following graphs prove it: Yes.
As one can see on the graphic, before the switch to the physical NTP server, many spikes of offsets can be seen. This happened on both physical and virtual servers, has therefore nothing to do with the NTP client. Instead both physical and virtual servers received the same time from the virtual NTP server which itself presents its own time, synchronized with an external source. After the switch to a physical NTP server, there are no offset spikes anymore and the whole synchronization is much steadier.
Claudio from Switzerland wrote on Jul 15th, 2012:
In my case the NTP server was accessible under a DNS name 'time.something.local' which pointed to a virtual server running NTP. In week 17 this DNS name changed its IP address pointing now to a physical server. After the DNS change I checked 4 different (client) hosts to compare their behavior: 2 physical and 2 virtual hosts.
And this is what you see in these four graphics.
Bruno Scota from Brazil wrote on Jul 15th, 2012:
Hi, i didn\'t understand this graphic. The first one, you turned physical ntp host at week 17? And the second one still virtual? equal the last one? don\'t get it. Can you give me more details? i\'m asking cause we\'ve got this same problem in our company. Your Article is very interesting. Thank you!
Personal Internet VMware PHP Linux Shell Bluecoat Proxy Windows Hardware Virtualization Nagios MySQL DB Monitoring Mail Android Network Wyse Hacks Tomcat Postgres Apple Mac Backup BSD ZFS Solaris SmartOS Unix Multimedia Perl Database MongoDB CMS OTRS FreeBSD Wordpress LXC Nginx Proxmox DNS Graphics GlusterFS Security Chef HAProxy Icinga Ansible HTML MariaDB Containers Rancher Docker AWS ELK Kibana Logstash Filebeat Varnish PGSQL PostgreSQL ElasticSearch CouchDB Bash Macintosh Container Minio Grafana InfluxDB Databases NFS OSSEC SystemD Java Zoneminder Surveillance Elasticsearch SSL TLS Icingaweb2 Cloud Wireless Kubernetes Ubuntu