Vmware ESXi (3.5) and RHEL (5.1) : Timekeeping Woes

Brian O'Mahony brian.omahony at curamsoftware.com
Wed Sep 16 03:21:55 CDT 2009


Jack

Thanks for the in depth explanation. This is pretty much what I was looking for.

Im going to disable the local lines, 1271.127.1.0 and fudge stratum 10. Add the tinker panic 0.

Just a s a matter of interest, the Host has 48Gig of Ram, where there ius 4Gb assigned to this guest, even though on average it uses between 400M and 1.4Gig. Would this cause issues that we are seeing?

Thank
B

From: Roehrig, Jack (John) [mailto:Jack.Roehrig at ask.com]
Sent: 15 September 2009 17:53
To: Brian O'Mahony; linux-poweredge at lists.us.dell.com
Subject: RE: Vmware ESXi (3.5) and RHEL (5.1) : Timekeeping Woes

While there are many timekeeping issues with VMs, most of them are specifically related to suspending machines and vmotioning machines. What you seem to be experiencing is an unstable clock frequency. When NTP detects clock frequency instability, it panics and quits. Several thing can cause this clock tick problem, but the most common we've noticed is utilization of the VM's swap file. If a guest exists on a host that has far more memory allocated to it than is committed in RAM (check Committed_AS), the ESX host may detect the LRU memory and page it out to disk. When the VM accesses this memory, ESX will swap it in and out of physical RAM. This causes horrible slowness on the VM and terrible time skew. You can check to see if your ESX host has paged memory to disk with the following command:

/usr/bin/esxtop -b -d 2 -n 1 | cut -d',' -f 40 | grep -v esx | tr -d '"' | awk '{printf "%.0f",$1}'

There are many conditions that can cause the VM's swap file to be accessed, but VMware engineers will not disclose the algorithms used to control this. If the sum of allocated memory to all guests than is more than available on the host, ESX may utilize the VMs swap. We monitor our ESX hosts with a cron job and SNMP traps to detect when ESX machines are utilizing swap.

HTH
-Jack Roehrig


From: linux-poweredge-bounces at lists.us.dell.com [mailto:linux-poweredge-bounces at lists.us.dell.com] On Behalf Of Brian O'Mahony
Sent: Tuesday, September 15, 2009 4:45 AM
To: linux-poweredge at lists.us.dell.com
Subject: Vmware ESXi (3.5) and RHEL (5.1) : Timekeeping Woes

I may have posted this here previously, and if not I know I spoke to Dell support, whom advised me to make sure that the "Synchronize guest time with host" was turned off.

Basically I have a RHEL5.1 server. It has the ntpd service running. This seems to stop every now and again. It took me quite some time to organize downtime on this VM, so I only got to turn off the option in setting last week.

Here is the log from messages:

messages:Sep 13 10:28:07 curzilla ntpd[2593]: synchronized to LOCAL(0), stratum 10
messages:Sep 13 11:35:50 curzilla ntpd[2593]: synchronized to 172.16.164.100, stratum 4
messages:Sep 13 15:18:10 curzilla ntpd[2593]: synchronized to LOCAL(0), stratum 10
messages:Sep 13 19:33:29 curzilla ntpd[2593]: synchronized to 172.16.164.100, stratum 4
messages:Sep 14 08:04:52 curzilla ntpd[2593]: synchronized to LOCAL(0), stratum 10
messages:Sep 14 09:30:14 curzilla ntpd[2593]: synchronized to 172.16.164.100, stratum 4
messages:Sep 14 22:01:36 curzilla ntpd[2593]: synchronized to LOCAL(0), stratum 10
messages:Sep 15 01:10:27 curzilla ntpd[2593]: synchronized to 172.16.164.100, stratum 4
messages:Sep 15 01:26:28 curzilla ntpd[2593]: time correction of 2232 seconds exceeds sanity limit (1000); set clock manually to the
 correct UTC time.



Anyone have any ideas/suggestions?

B





The information in this email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else

is unauthorized. If you are not the intended recipient, any disclosure,

copying, distribution or any action taken or omitted to be taken in reliance

on it, is prohibited and may be unlawful. If you are not the intended

addressee please contact the sender and dispose of this e-mail. Thank you.


The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you are not the intended
addressee please contact the sender and dispose of this e-mail. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20090916/d18cad98/attachment-0001.htm 


More information about the Linux-PowerEdge mailing list