VMware

This Question is Answered

1 "correct" answer available (10 pts)
8 Replies Last post: Apr 9, 2008 11:24 AM by jbbroccard  

Time drifts on Red Hat 5.1 (Unbrkbl Linux) on top on VMware server posted: Apr 8, 2008 10:31 AM

Click to view jbbroccard's profile Novice 6 posts since
Apr 8, 2008
Hi,

I've been looking around the net to see if the suggested solutions could help me, unfortunately it didn't.

I installed VMware Server (VMware Server 1.0.2 build-39867) on top of Ubuntu 7.04 (2.6.20-15-generic #2 SMP Sun Apr 15 06:17:24 UTC 2007 x86_64 GNU/Linux) which is installed on a Dell Poweredge server (2 x 4 core@1.86Ghz, 8GB).

Then I started to deploy virtual machines: ubuntu, debian, everything was fine.

Then I had to install Red Hat product from Oracle E-delivery (for Oracle Server), and I noticed that the time was drifting terribly, like 4-6 times slower than my Ubuntus.

I tried several Red Hat mediapack: 4.5 32-bit and 64-bit , 5.0 32-bit and 64-bit yesterday 5.1 64-bit with develepment kit in order to have the Kernel sources.

First, I installed vmware-tools provided within the VMware server kit (linux.iso), btw it says "vmware tools out of date", don't think it's a big deal...

I checked kernel compilation:

5:# define HZ CONFIG_HZ / Internal kernel timer frequency /
6:# define USER_HZ 100 / .. some user interfaces are in "ticks /

I changed kernel boot options:

kernel /vmlinuz-2.6.18-53.el5 ro root=/dev/VolGroup00/LogVol00 clock=pmtmr

OR

kernel /vmlinuz-2.6.18-53.el5 ro root=/dev/VolGroup00/LogVol00 clock=pit

OR

kernel /vmlinuz-2.6.18-53.el5 ro root=/dev/VolGroup00/LogVol00 clock=pit nosmp noapic nolapic

I also changed <my-vm>.vmx file with:

tools.syncTime = "TRUE"
tools.syncTime.period = "1"

I also tried to add:

host.cpukHz = 1860000
host.noTSC = TRUE
ptsc.noTSC = TRUE

Nothing works, it's still slow... I'm going mad with this Red Hat.

The only way to fasten the clock is to run hwclock in background with no wait but it consumes 40% of cpu time.

But I still need more ticks !

Can anyone help ?

Click to view AWo's profile Champion vExpert 4,162 posts since
Nov 27, 2003
Enable the VMware TimeTracker logging:

Add
timeTracker.periodicStats="True"
timeTracker.statsIntercal="10" (for 10 sec. tracking intervall"

to the guests .vmx file (guest needs to be restarted) and post the entries from vmware.log (start with "TimeTrackerStats").

General background:

The issue with virtualization and (mostly) Linux guests is, that Linux (and other OS's, too) are using the PIT (Programmable Interrupt Timer) to count the timer ticks. Linux requests a timer interrupt in frequencies of 100 - 1000 Hz per OS instance + per (virtual) processor (n+1). One bad thing about that is, that this will consume ressources, even if the system itself is idle.

The other bad thing is that only the guest which actually owns the processor receives the interrupt, so many interrupts are lost (Lost Timer Tick). That's why the time of a virtualized machine would always run too slow, if there is no compensation.
Windows uses the PIT, too, and other different mechanisms/time sources which can even change if you install software, for example Apple's Quick Time.

As loosing these ticks happens on hardware, as well, there is a Lost Timer Tick correction algorithm within Linux to compensate this. This works well enough on pure hardware.
But there's a second compensation mechanism if you run it onVMware: VMware tracks the interrupts lost and sends them in a timely compressed manner to the guest later (in fact not all are send, some lost ticks needs to be deleted by the Vmware time management). That's the reason why the time doesn't run consistent and seems to "jump" sometimes.

So there are two mechanisms to keep the time accurate and that could lead to a clock running too fast (overcompensation). There is no way to slow it down with the VMware tools, yet, nor do they set the time back. Slowing down the clock is planned for a future release of the tools.

The suboptimal usage of the PIT has changed from Kernel 2.6.18 for 32 Bit / 2.6.21 64 Bit. In newer Kernels Linux uses a different lock source (TSC, Time Stamp Counter) where it can read the time directly (has not to count the ticks to generate the time) and without using an interrupts. Another advantage is that his time device can be read faster that the PIT.

AWo

Click to view awyork's profile Enthusiast 46 posts since
Apr 23, 2007
You will need X.

Either connect through the console or ssh -Y <youracct>@<yourbox>

run vmware-toolbox
check the box talking about syncing time
close that app

Make sure VMware-Guestd is running

(as root)
service vmware-tools status

service vmware-tools start (to get it to run)

give it a few seconds and check your system time.

I tried all of that other stuff and found this works the best.
Good luck and may the force be with you, always ;)
Click to view larstr's profile Virtuoso vExpert 2,401 posts since
Mar 11, 2004
Or you could use the already precompiled 100Hz RH kernels (kernel-vm) from the CentOS team:
http://dev.centos.org/centos/4/testing/
http://dev.centos.org/centos/5/testing/

In 5.1 (and 5.2) it's also possible to lower the Hz by using the divider option, but then you'll break the clock sync with the pit.

Lars
Click to view larstr's profile Virtuoso vExpert 2,401 posts since
Mar 11, 2004
That means all pre-compiled Centos kernels are @100HZ ?

No, it means that all kernels that are branded kernel-vm are compiled to 100Hz.

Lars

VMware Beta Programs

Want to be Considered for Future Beta Programs?

Learn More

VMware Developer

Download SDKs, APIs, videos,
training, and more in the Developer community.

Learn More

Developer
Sample Code

Increase your developer productivity with VMware API sample code.

Learn More

VMworld
Sessions & Labs

Online access to the latest VMworld Sessions & Labs and online services.

Learn more

Purchase PSO Credits Online

Purchase credits to redeem training and consulting services online.

Buy Now

Community Hardware Software

View reported configurations or report your own.

Learn More

Only VMware ... Delivers Nexus 1000V

Ensure consistent, policy-based network capabilities to virtual machines across your data center.

Learn More

Communities