• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Debian guest on VMWare ESX Server time problem

Brazen

Diamond Member
Is anybody else using Debian as a guest OS in a virtual machine on any VMWare product? I'm using it on VMWare ESX Server 3 and I'm having the problem of the Debian Server is gaining time. After a week it is 3 minutes fast.

I've install vmware tools and set the timeSync = TRUE. I even found a VMWare document on this which said to pass some kernel options in the boot loader, which I did, but this is still happening.

Any ideas? I'm using kernel 2.6.8-3-686.
 
clock=pit nosmp noapic nolapic

However, I just happened to think of checking the time on the ESX Servers. I have ntp set up on them all, which has worked well for me on linux servers, so I didn't figure the ESX servers would be fine for time. Anyway, the ESX Server is right on time with the Debian guest. In addition, each ESX Server is set up exactly the same, same hardware, same ntp.conf, etc, but they each have different time, all of which are fast.

ESX Server 3 is just a slightly modified Redhat Enterprise Linux with some VMWare rpms installed (I think it's RHEL 3, but could be RHEL 4). Right now I'm having it sync with our two Windows Domain Controllers, but maybe it would be better to have them sync with the Stratum 1 servers.
 
Well, I just wiped out the ntp.conf and started over and used the #.pool.ntp.org servers. It seems to be working fine now.
 
I think you should blame the government, it's probably a conspiracy against you. :roll:

How did you set up the ntp servers on the ESX boxes initially? Have you made any changes since that may be related?

Just curious if you're running into an issue with ESX breaking NTP in Linux or vice-versa.
 
Originally posted by: spyordie007
I think you should blame the government, it's probably a conspiracy against you. :roll:

How did you set up the ntp servers on the ESX boxes initially? Have you made any changes since that may be related?

Just curious if you're running into an issue with ESX breaking NTP in Linux or vice-versa.

I think I just followed VMWare's guide to setting up ntp on ESX server initially. I had found the guide on the web and made it into a pdf. Just now, I went ahead and went back out to the web and found the guide which said it had been updated with changes to the ntp.conf. I followed the new guide and used the ntp pool instead of our local servers.

I haven't gone through to see what is different. The original ntp.conf files are kind of a mess since they are loaded with documentation. I don't know why I didn't just wipe out the ntp.conf and start blank, which is what I usually do with all conf files. I think I was afraid that VMWare's ntp may be funky somehow. This new guide though pretty much had me set up standard directives for an ntp.conf.

I don't know if it was Windows or something funky in the original ntp.conf, but it's working now and I wanted to start using the ntp pool anyway since I will eventually be moving our domain controllers into virtual machines. And by the way, I think nothinman was just being humorously facetious with his "blame Windows" comment.
 
here's the new ntp.conf:
restrict default kod nomodify notrap nopeer
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
driftfile /var/lib/ntp/drift

and here's the old:
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default nomodify notrap noquery
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
# -- CLIENT NETWORK -------
# Permit systems on this network to synchronize with this
# time service. Do not permit those systems to modify the
# configuration of this service. Also, do not use those
# systems as peers for synchronization.
# restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# --- OUR TIMESERVERS -----
# server 0.pool.ntp.org
# server 1.pool.ntp.org
# server 2.pool.ntp.org
server 192.168.3.3
server 192.168.3.4
# --- NTP MULTICASTCLIENT ---
#multicastclient # listen on default 224.0.1.1
# restrict 224.0.1.1 mask 255.255.255.255 nomodify notrap
# restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# --- GENERAL CONFIGURATION ---
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
# server 127.127.1.0 # local clock
# fudge 127.127.1.0 stratum 10
#
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
#
# Keys file. If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
#
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will. Note also that
# ntpd is started with a -A flag, disabling authentication, that
# will have to be removed as well.
#
keys /etc/ntp/keys
 
I think nothinman was just being humorously facetious with his "blame Windows" comment.
I know, so was I with my government conspiracy comment 😉

Strange that it's having issues with their config, it's long but there still isn't much to it if you consider all that is commented out...
 
Back
Top