Kiss-o’-Death Packet – Time Then and Now
Posted by Reprinted Article on 21 August 2013 08:06 AM
In the days where CMOS and on board clocks ruled the roost time was rock solid. Between atomic clocks that became common place on the Internet and CMOS one never really had to worry too much about it. If there was a bit of a difference the OS would shift the CMOS clock back into alignment. Case closed.
The difference with virtualization is the separation between the OS and the hardware.
Now, one would think that all we really need to do is enable the sync between host and guest via their guest utilities. But a DC cannot be dependent on the host because the guest is not allowed to adjust the time _on_ the host if it is out of sync. If the host carries the DC way out of sync with the rest of the network toast is made.
We’ve seen clusters go down because of time being out of whack.
Our timing post has a registry edit in it that we used to do on 2008 RTM that allowed the guest to ping the host for time but once the OS was up and running it would pick up from ntp.org or whatever.
That registry edit is now there by default from what we have seen.
The time structures were never intended to compensate for today’s virtualization environment since no one could have envisioned the setup in the first place back then.
Now, look up “Kiss-o’-Death Packet” (NTP.ORG site). And we see why we need to be _very_ careful around the time setup on our virtualization platforms.
This packet is the primary reason we make sure we have a physical box set up on the local network to poll for the correct time within the virtualization environment. That box polls ntp.org. The virtualized DC polls that box as it will not stop answering like ntp.org would if polls are more frequent.
Imagine a high load VM setup where the PDC is set to poll ntp.org but the admin set up a script to run the poll a lot more frequently. After exhausting the ntp.org servers in its list due to Kiss-o'-Death Packets it would be hooped and time would go awry on that network.
Since we don’t work with VMware we personally am not aware of how that server setup can work as an NTP server.
We do, however, highly suggest making sure being aware of the perils of time when virtualized.
Chef de partie in the SMBKitchen