We need to setup an internal NTP server. Because this server will pretty much ONLY be a time server I was thinking of just creating a VM for it. However, Googling around it appears that there there might be serious clock drifting issues with VM servers. So, is running our NTP server in a VM a completely dumb idea?
Thanks, John
Time can be a problem inside VMs but by the same token if done correctly can be as accurate as a physical machine. It may seem odd but I'm a huge fan of using my switches (always Cisco in my world) as my NTP sources - not only are they easy to setup as such but it they have the handy benefit of being your DG too usually - see if your switches can do this too.
(This question might better fit on StackOverflow's sister site, ServerFault.com.)
Yes, clock drift can be more drastic on hosted virtual machines when compared with physical hardware. (Normally you would set the VMware host server to sync with your NTP server of choice, then have the VMware Tools in each of the virtual machines sync with their parent host.) But I'm not sure it's a reason to avoid a virtual NTP server...
On the other hand, have you considered other options? For example, NTP is such a lightweight service that it could be added to just about any other production server with no load increase. (Heck, if you have a Windows domain, one of your Active Directory controllers is already acting as an NTP server for the domain members.) Or, is it possible to use an existing NTP server from the Internet (see http://www.pool.ntp.org/en/ for a huge list)?
In general, running an authoritative NTP server on a VM is a very bad idea. It can be difficult enough just getting a VM to have a consistently accurate time, to within a second.
You really need to run it on metal of some kind, but as ewall said it's usually a light weight service (if it's only for internal usage). We generally combine it with some other kind of server already running on hardware, such as for example DHCP or DNS servers.
Set up at least two, make them peers of each others and synchronize them to a known set of good servers. What those might be depends on where you are; check with your ISP(s), national authorities on time, etc. Pool.ntp.org might be OK or might not be good enough, depending on your requirements.
Why not make use of the ntpd running on ESXi itself as your local ntp server?
Firstly setup your time sync as per normal on the ESXi host pointing to one or more external ntp servers (check out pool.ntp.org).
In order to allow other hosts to make use of ntpd running on ESXi you will have to add a custom firewall rule to allow it to be used as a server. The easiest way to add the firewall rules is by running the following at an ESXi shell:
esxcli software acceptance set --level CommunitySupported
esxcli software vib install -v http://files.v-front.de/fwenable-ntpd-1.2.0.x86_64.vib
Once complete simply tick the box next to "NTP Daemon" in your ESXi servers Firewall Properties. Now you can have your cake and eat it too!
Source: http://www.v-front.de/2012/01/howto-use-esxi-5-as-ntp-server-or-howto.html
Que? Are you trying to generate evidence of proper time management or just to calibrate a set of machines? It is a very very different process for evidence generation, and none of the existing systems including NTP run as a daemon alone provide.
As to the virtualized platforms they are abstracted from reality by their virtualization managers and their runtime framework so expecting them to pass real-time information to their calling processes is silly. Besides if the virtualized environment is designed properly the time data in it is, well, irrelevant because the virtualized system will log to a fixed real-world logging system as its infrastructure, so the real issue is when log entries were entered into the system by the logger. Its what generates the provable sequence of events.
One solution You could do what I recommended to a client today - program the VM instances to do pull based time setting from a pre-defined source by coding the sources address into the NTP server key fields in the registry and then altering the polling values in the registry to make the client refresh its time of day every minute. The effect of this is to create an Event Log entry in two separate log instances once a minute insuring there is a culpable tracking. Then who cares about what AD or the state-awakening process for the VM's does
You need a partner to make NTP work.. As to the evidence issue - NTP must have a partnership with known sources to be reliable. It's a UDP/IP based protocol with limited capabilities for actually securing the data in transport. It is also subject to many simple attacks like MAN IN THE MIDDLE or REPLAY type attacks. As such if you use it as evidence it really needs a partner and someone who has pre-approved templates for operations.
I could on about NTP and it's misuse and misunderstanding today as to what it produces as evidence. But that said NTP has the ability to be used as a reliable source of evidence with some bolting down and partnerships with the NTP providers.
I've had massive problems if using VMWare Server and a VM running NTP. VMWare ESXi works beautifully though.
Generally virtualization software vendors have guest tools (Vmware and Virtualbox do) to correct that problem, I experienced drifts before installing vmware guest tools on our ESX. Altough the time doesn't drift dramatically (a few seconds of max deviation) however it definately will have an impact if you host a timeserver on it.
Time being generally based on counting processor cycles maybe some virtualization platforms support guaranteeing the frequency of CPUs given to a vm, that could help.
