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!
AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Database Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera Git GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Icingaweb Icingaweb2 Influx Internet Java KVM Kibana Kodi Kubernetes LVM LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Office PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMWare VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder