Welcome to the community
It is not recommended to use ESXi as NTP server. Becuase ESXI is busy all time in scheduling CPU to the Virtual machine and in this case any wait time for CPU will lead to time sync problem.
Still if you want to use ESXI as NTP server us can.
Make sure the ESXI host as internet connection and configure ESXi host NTP setting to get time from the NTP server over internet like pool.ntp.org, etc.
Now in all virtual machine set to sync with ESXI host or configure ESXi host as ntp server to it to get time.
Usual it is made that DC will provide time services to all servers.
Agreed with Virtualinfra - for a production environment it would not be recommended at all to run a NTP server on an ESXi host.
ESXi is purpose built as a hypervisor, so ideally you should use an OS that is purpose built for NTP functions as your time server. In most cases you use a Domain Controller for NTP to your ESXi hosts, or set them to use NTP from a pool of NTP servers on the Internet
I agree with both of you that it might not be the optimal solution, but in our ESX 4.0 (not ESXi) environment we have been using our ESX servers as NTP servers for several years and it worked very well. I am also aware of how to configure a DC to distribute the time to all domain members.
The reason why we used our ESX servers as NTP servers is quite simple, imho a NTP server should run on physical hardware and have a physical RTC. If you run your NTP server(s) in a VM, the NTP server software never actually sees or works with a physical RTC, but the "virtual RTC" provided by the hypervisor which never is as accurate as a physical RTC due to the virtualization layer. Because in many environments the ESX servers are the only remaining physical boxes, they are predestined to act as the NTP server as well. That is just my opinion, others might differ on this subject.
So, my question remains (regardless if its "not recommended"), is there any way to configure an ESXi 5.0 to natively act as an NTP server? "No" would be a perfectly satisfying answer, because i do expect that ESXi 5.0 does not even HAVE the NTP server portion in its code anymore (as ESX used to have).
ESX has a service console, where you can install and configure NTP it as a time server.
But things change in ESXi the archectiture is competely changed here, it doesnt have services console and its solely ment for only providing virtualization.
Still you have option to sync VM with esxi to take time in vmware tools options inside VM. once you configure ESXi to take time from internet.
But the CPU usage on the ESXi is high the time wont be in sync properly to the VM even same in esx, i belive.
refer belo doc time keeping bestpractice for a VM.
Award points for the helpful and correct answer by clicking the below tab
For my sins - I'll disagree with all the above.
If you have gone the whole hog and virtualized your entire infrastucture then pretty much the only physical clocks will be in your ESXis. A NTP server will not work particularly well in a VM on its own because its "hardware" clock is faked.
ESXis all have an ntp daemon running anyway and the "load" of using them as servers is not a great deal. Watch the traffic with Wireshark. Not sure how to get the load of a process on an ESXi but on my desktop ntpd uses a pretty tiny amount of RAM and doesn't even feature in "top".
I personally recommend that you sync your ESXi to 5 external sources, something like this:
Set your VM DCs to use their host as the time source via the tick box in VM guest tools. Actually you only really need to set the DC with the PDC emulator role - the rest of your domain will follow via SNTP. Ignore/hide the best practice "errors" in server manager for 2008(r2) relating to no ntp time source!
Linux et al could use ntpd or openntpd and sync to the ESXis or to the same set of external ntp sources as above.
I chose five sources because ntp often drifts with "only" three.
I run the above config on many customer and our own sites and time has stayed provably stable for several years. You usually get down to around a 1 milli-second offset after a while.
As i have already stated, i am well aware of how to configure an ESX/ESXi environment for proper (in my opinion) time sync.
The linked document refers to ESX/ESXi 4 and Workstation 7 btw, although i guess the basics still apply to ESXi 5.
That is exactly the way i configure my ESX servers (almost, i only use 4 NTP servers). My DCs are configured as NTP clients as well (syncing via NTP from the ESX servers) and distributing time to the domain members by NTDS and NTP (w32time NTP server is active as well). The VMware Tools time sync. is active as well. I know, it is not recommended to sync via NTP and VMware Tools, but, VMware Tools can only correct time shift in one direction (forward, if i remember correctly) so to counter backward time shifts (which unfortunately have happened in our environment) an additional sync. via NTP gets rid of those.
Anyone who wants the points could simply answer my original question, probably with a "No" ;-)
I did not intend that this thread evolves into a generic time sync. discussion, i rather wanted a simple answer if somehow ESXi 5 can nativley (without an additional Windows DC, vMA or whatever) act a NTP server.
softconsult, I see your point about the hardware clocks being more accurate on the physical hardware after you explained how you saw it - it kinds of makes sense actually and is an interesting topic now that I see two good points for each side of the story.
Anyway, regarding your yes/no question, I spent a little bit of time over lunch today trying to figure out a way of installing a custom service into an ESXi 5 host and didn't have too much luck - I was aiming to get you what you wanted to know - a yes/no answer!
Anyway, my short investigation turned up that it is obviously going to be a hacky type of method to get it installed if it is possible (as you would expect with ESXi being locked down), but if it is possible, I was thinking it would probably be via a custom VIB that you would use. You obviously can't use yum or whatever to install a service/bit of software. So for now, I am going to say no its not possible, pending further investigation of course I would like to know the answer to your question now too, so I'll see what else I can find in my spare time. If it is possible, I am guessing it will be via a VIB or something along those lines.
ESXi 5.0 comes with an NTP daemon (/sbin/ntpd)!! In fact it is the same binary that acts as a NTP client, but is also able to act as a NTP server if properly configured.
By default it is to be used only by the machine itself (localhost) through the line
I haven't tried that myself, but if you follow these steps you will most probable be able to use an ESXi 5.0 box as NTP server for other computers:
1. Enable the NTP client via the vSphere Client GUI.
2. Log in to the ESXi console and change /etc/ntp.conf to allow access from anywhere by removing the "restrict 127.0.0.1" line and adding a restrict line for your subnet like described here: http://support.ntp.org/bin/view/Support/AccessRestrictions
3. Now you need to configure the firewall to allow incoming NTP queries (that's on UDP port 123). The following article describes how you create the necessary custom firewall rule: http://www.virtuallyghetto.com/2011/07/how-to-create-custom-firewall-rules-in.html
There you will also find instructions on how to make the changes permanent to the system.
Another option to make the change permanent is to create and install a custom VIB file as suggested by Shoganator. You can use my script TGZ2VIB5.cmd for that. It is part of ESXi-Customizer available here: http://esxi-customizer.v-front.de
This threat made me really curious about NTP in ESXi and I digged into this to come up with a complete solution:
1. In the vSphere client configure and enable the NTP Client for the host. Make sure that you choose to set its Startup Policy to "Start and stop with host".
2. I created a custom VIB file that adds a firewall rule for incoming NTP traffic. Find it attached here, copy it to an ESXi accessible datastore and install it inside an ESXi shell with the following commands:
# esxcli software acceptance set --level CommunitySupported
# esxcli software vib install -v /full/path/to/fwenable-ntpd-1.2.0.x86_64.vib
(the first command is needed for ESXi to accept the custom VIB, because it does not include a trusted signature file)
This will permanently install a file /etc/vmware/firewall/ntpd.xml with the following contents:<!-- Firewall configuration information for NTP Daemon --><ConfigRoot><service><id>NTP Daemon</id><rule id='0000'><direction>inbound</direction><protocol>udp</protocol><porttype>dst</porttype><port>123</port></rule><enabled>false</enabled><required>false</required></service></ConfigRoot>
3. Now look at the Security Profile configuration of the host with the vSphere Client. Refresh the Firewall properties here, then edit them: You will notice a new rule labeled "NTP Daemon". Check that rule and close the dialog with OK to open the associated firewall port (UDP 123) for incoming traffic.
That's it. You can now use the ESXi 5.0 as NTP server from any machine that can connect to it!
In my previous post I stated that you also need to edit /etc/ntp.conf, but this is not true. By default it already allows queries from any client.
It's hard to find a good explanation of how the "restrict" lines work in /etc/ntp.conf. The best reference I could find is here: http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch24_:_The_NTP_Server#The_.2Fetc.2Fntp.conf_File
I tested that procedure and it worked for me. Have fun!
I was wondering why you go through all the trouble of creating your vib install bits when VMware has published this KB to handle the custom XML file:
Create your ntpd.xml per the VMware Security Guide linked in the KB in a common datastore then edit /etc/rc.local per the KB instructions to copy it into place and refresh the firewall at startup. Works great. Here's my ntpd.xml just for kicks:
<!-- Custom NTP Firewall configuration information -->
I don't use this setting for NTP as a server on the ESXi host, rather for Nagios monitoring so it can poke at NTP then compare to the NTP source for accuracy to be sure NTP is keeping in sync.
I was aware of that KB article, but I consider the procedure described there a workaround rather than a solution, because adding the XML file this way does not make it inherent in the system and introduces a dependency to an external resource (the datastore) that you need to take care of during the whole lifecycle of the system.
In contrast the VIB file is something that you can "install and forget".
I just like clean solutions ...
You make a good point about the dependency on an external datastore. We prefer to install ESXi on RAID1 instead of using a USB stick boot device so we technically have a local datastore on each host I could use. While that removes the dependency on the external datastore, it doesn't remove the need to create the file locally on each ESXi host and/or create and use your vib install method. Either method involves manually changing something on the host I'm kind of disappointed we even have to spend time on. I honestly can't figure out why VMware chose to block inbound NTP in the default firewall AND not give the user the ability to decide on/off.