hicksj,

The purpose of the ntpd daemon is to poll the time servers and adjust the clock accordingly. In a real machine, this works fine. However, under vmware, the clock seems to drift a lot. In this case, I force a time adjustment via the ntpdate program instead of the usual ntpd time slewing method. I have the cron daemon sync up every minute. In addition, I wrote a small script that will check to see if ntpd is running. If it is not, it will restart itself (which also kick starts another force time adjustment). This check is also done every minute. One more script was made that sync'd the system clock to the hardware clock (guest vm clock in nvram file?) every 2 seconds. Already part of the original design, the vmx file is configured not to sync the guest virtual machine with the host system clock. All these work arounds should hopefully make the system more stable.

Before the workarounds, the ntpd process may kill itself because the time offset/jitter surpassed a certain millisecond threshold. The windows "net time" command would still work. However, the clock will drift significantly and no clients can communicate with the ntpserver via udp/tcp port 123 since the process is killed.

Other than that, I cleaned up the generation of the ntp.conf file as I noticed duplicate ips from time to time.

So, I hope all these fixes essentially makes the vm app a true "final" release =).

Thanks all for the comments and bug notices!

-Mervin Yap

loetmann,

Thanks for the update. I will investigate the ide version today. Since the new versions of VMware supports scsi, I'm wondering if I should just remove the ide version from the page?

Have your tried using the "ntpdate -u" flag? On a few of my linux boxes, the time won't sync unless I use the "-u flag".

Let me know if this works. If not, then I'll have to modify the ntp.conf generation script.

Thanks,
-Mervin Yap

kamphor,
first of all, thanks for your prompt reply and reaction. I had to figure out a lot of issues to get this VM up and running.

Obviously, as allready said before in this thread, RTC under VMWare is a major challenge.
I use to run VMServer 1.0.4 under 32-bit Debian etch with a 2.6.18 Kernel on a quad-XEON machine (Dell 860).
At the time I started evaluating your NTP-VM I ran the standard Server-bigmem kernel. Previously I solved my RTC and clock skew problems with some also debian-based guest systems with migrating to Ubuntu 7.10-JEOS, which is somewhat more performant.

Since I seriously wanted to give NTP-VM a chance I decided yesterday to take the bully by the horns in order to solve this RTC-issue permanently. With a little help of google and friends I figured out that there are two factors to be considered:

1. HPET_EMULATE_RTC has to be activated statical and not as a Module:
2. Changing timer frequency from 250Hz to 1000Hz ( as vmware even propagates, by the way)

This was necessary to avoid the heavy clock skew I encountered in NTP-VM and the boring messages on the server console: kernel: rtc: lost some interrupts at 512Hz.

Now NTP-VM didn't stumble any more behind. But after even waiting for hours ntp to become synchronized (stratum evaluation) I remembered another trick I used some time ago: kernel boot parameters in the guest machine.

After changing following parameters in menu.lst to:

• clock=pit

+ noapic nolapic nosmp

nearly everything is allright. NTP is evaluating stratum within minutes and the service becomes availlable also for *nix machines. Fine.

But there are three issues left:

I am not able to start up the VM without interacting with the console to give this starting udev thing a hit with CTRL-C. It allways stopped at this point. First I thought this was due to clock skew or clock frequency ratio. But no chance.

After your last update I tried again the scsi version. For me its now brocken. While uncompressing the boot image it dies. So I changed to IDE-version which now works fine with said modifications to server and guest.

Somewhere in your descriptions on vmnet is mentioned that vmware tools should be installed. My Server-console complains about missing vmware tools.

Since this VM doesn't have even a sshd running, I am not able to shut it down by remote scripting.

Excuse my epic description and thanks a lot for your work and support.

Regards

• Ralf Kuehnbaum-Grashorn

Hello kamphor,

yes, I have waited definately more than the requested 10 sec.

Regarding clock pit there was a typo in my posting: I have removed "clock=pit" and added "noapic nolapic nosmp" in menu.lst

The vmware-console complains about missing vmwaretools. chkconfig --list says it should be on for init-levels 2 to 5.

I tried also shutting down the vm: It was a hard one or just pulling the power-cord.

I would apreciate in choosing a more actual distribution. If you are not sticked with mandriva, give ubunto Jeos a try. I ran it allready with a footprint of 32 MB for a secondary DNS.

-Ralf

Ralf,

It sounds like you have the NTP appliance working well, or possibly have one working under Jeos. If so, would you consider submitting it as an appliance? There just aren't many dedicated NTP appliances to choose from. I would be willing, but I'm still VERY new to Linux.

Note to kamphor - I do appreciate all the work you have done thus far - I just can't seem to get it to work in my environment (ESX 3.02).

Kamphor,

Thanks for doing this project, the appliance is killer. I looked around quite a bit and found that this udev bug has been around in Mandriva for some time.

In order to get around the hang at "Start udev", since we do not use wireless NIC's in our ESX servers:

edit /etc/modprobe.conf and add the following line:

"alias ipw2200 off"

-Tom

magnetron,

if you go to the download page, I believe the ide w/vmxnet version should work fine with the free vmplayer. The scsi version w/e1000 should work fine with the free vmware server 1.0.x. I have yet to test it with vmware server 2.0. If anyone has a test environment for vmware server 2.0, it would help greatly if someone can supply feedback on testing it in that version.

respectfully,
Mervin Yap