CactiEZ loosing time in vmware Server on Windows 2003

[Dunkelzahn]

Hi,

I now had CactiEZ running for some weeks and as looking through the graphs we recognized, that the date and times are wrong. After checking the local time regularly it seems, that the vm is loosing almost 50% of the time, so afte one hour, cacti showed only half of it, making all graphs a bit useless.

Searching the internet and this forum showed up some common problems with linux in vmware server going to fast or to slow, but nothing was helpfull so far. As the easiest solution, I tried to get ntp up an running, but after some updates it gets a huge jitter on all ntp server (External and internal) and keeps on using the local clock.

Has anyone here had this before and are there any ideas how to solve it? One suggested installing vmware tools. How can I do this in CactiEZ?

I really appreciate any help you can give me, as this is a bit frustrating.

Regards

Maik

[rony]

Install the VMware tools and enable host time sync.

[mcutting]

Faling that, set a CRON job that syncs the time with ntp.pool.org, for example. I ran CactiEZCD for a while on a VM machine, and had set a CRON job that ran every minute to keep the time correct !

[Dunkelzahn]

@rony I know it is a stupid question, but how do I install vmware tools?

@mcutting I tried to set ntpd up with several External and even internal ntp servers. Latest after the 3rd or 4th pull I have a jitter of 40000+. Can you tell me, what CRON job you ran?

I just try to get a foot into this and what sounds easy for you is a real task for me. But anyway thanks for your help so far

[mcutting]

[Dunkelzahn]

Thanks, thats exactly what solved my problem. Not a really good solution, as I still loose 10-20 seconds per minute, but nobody will see it in the cacti graphs

[cigamit]

Yep, this is a known issue with VMWare and the kernel that is used in CentOS 4.0. CentOS 5.0 has a newer kernel which takes care of this issue for you, or you can install VMWare Tools or there is a simple kernel parameter that you can use to fix it.

[Mika2006]

interrestinf topic

[streaker69]

[laffen99]

We have this problem with various Linux distributions and FreeBSD 5.x/6.x. Solution was to run ntpdate every minute in cron against our internal NTP server.

[cigamit]

In theory there is a issue with running an update every minute. Since you are losing time (I lost 1 sec for every 2 secs) the time between cron jobs isnt exactly a minute, in my case it was 1.5 mins.

You are trying to use a time based tool (cron) to fix a time loss issue, which isn't going to work well.

[Cova]

It's an issue with VMWare, not the guest OS running inside the VM - all virtualization software will have this problem in some way. Basically, the OS running inside the VM is not getting timer-ticks during the time it's not actively scheduled, and so it doesn't know how much time has passed. It also causes per-process CPU usage reporting in the guest OS to be wrong, as when the VM does get scheduled again VMWare will send a bunch of timer-ticks all at once to help it catch up, and the guest OS will assume that whatever process is running at the time got a LOT of CPU time even though it didn't really.

And the best way to fix it is to use VMWare tools installed into the guest OS, which will keep the clock in sync with the host OS. How to install the tools is slightly different for every guest OS, but almost always starts with choosing "Install VMWare Tools" (or something like that) from the VMWare console, which will mount a cd iso into the VMs cdrom with the tools on it. For linux there is both an RPM and a tarball of the tools - windows guests that CD will autorun and start the tools install.

[jpharvey]

It is an issue with VMWare.

I used to do the NTP thing every minute but let's face it it's an ugly solution.

There is a sure fire way to resolve it (which I have done), which is to recompile the kernel with a lower timer interrupt rate. This URL tells you what to set it to:
http://kb.vmware.com/selfservice/viewContent.do?externalId=1420
Note: None of the other suggestions in the preceeding article worked for me. Recompiling the kernel is the silver bullet - I'd recommend going straight to it.

This URL tells you everything you need to know about recompiling the CentOS kernel:
http://www.howtoforge.com/kernel_compilation_centos

It's a bit fiddly but really quite easy, although building the kernel can take a few hours.

JP

[knebb]

[fxef79]

The absolute quickest way I've found to correct this is to grab an updated kernel that's already compiled to 100 Hz. There's a reference to CentOS specific kernels here:
http://wiki.centos.org/TipsAndTricks/VMWare_Server
(which leads you here for a kernel that works on our wonderful CentOS 4.x based CactiEZ installs: http://people.centos.org/~hughesjr/vmware-kernels/4/i686/)

I've built several virtual cacti systems using cactiez on Windows 2003 hosts (VMWare Server 1.0.3), and within minutes can just download and install the kernel-2.6.9-55.0.2.EL.100HZ.i686.rpm.

I'm NOT a linux guy, by any means... so the mechanics of having to download/install all the additional bits and pieces necessary to recompile my own kernel on the already stripped down CactiEZ base is really "out of scope".

This fixes exactly the problem mentioned in the original post - which is that the virtual machine clock seems to run at about 1/2 speed.

I generally also add the various clock settings found in a bunch of the relavant VMware KB articles... particularly I append "noapic nosmp nolapic clock=pit acpi=no" to the kernel line in grub. However these clock settings, by themselves, have never fixed the problem. Only replacing the kernel has ever solved it outright for me.

This keeps the time darn near right on, without having to resort to running ntp once every minute or other crazy solutions, and without even having to install vmtools.