> Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek VAT BE 406.024.281, RPR Mechelen, ING 310-0092504-52, IBAN : BE64 3100 0925 0452, SWIFT : BBRUBEBB -----Original Message----- > From: redhat-list-bounces@xxxxxxxxxx > [mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of John Horne > Sent: woensdag 28 mei 2008 0:04 > To: General Red Hat Linux discussion list > Subject: Re: Linux server time getting out of sync frequently. > > On Tue, 2008-05-27 at 14:50 -0700, Josh Miller wrote: > > John Horne wrote: > > >> as i recall, there are a few parameters you can set > within the vmware app > > >> for the guest os, in order to sync the timing, and to > stop the skew from > > >> occuring... > > >> > > >> i think you might also have to modify the kernel startup > attributes. > > >> > > > The only solution I have found to work is to stop NTP on > the guest and > > > simply run ntpdate (getting the time from other reliable > server) every > > > hour or so via cron. The only 'solution' I have not tried > is rebuilding > > > the kernel. Suggestions like use the PIT time source on the kernel > > > startup line may well improve the timekeeping, but it > still loses time. > > > > Hi, coming into this late, but I have been very successful with the > > following solution: > > > > 1. make sure all ESX hosts are syncing time via NTP with a > reliable source > > 2. disable NTPD in all guests > > 3. set each guest to sync time via VMware tools by setting > > tools.SyncTime=TRUE > > 4. in each guest, on the kernel line in grub.conf, set > clock=pit and reboot > > > Tried it, but didn't work. The guests still lost time > (although the host > was still accurate). I don't know if this is still an issue for you. I haven't seen any report you got this solved so I thought I'd add our experience. A while ago we noticed severely degraded performance on some of our systems (running WebSphere deployment managers). And also noticed they were having problems syncing time. The ntpd daemon died just like in your situation. The systems would report 100% CPU usage while on the host system CPU utilization was close to nihil. Although CPU utilization inside a VM can not be reliably measured this decrepancy was huge. Our VM maintainer tried all sorts of tricks - moving the VM back and forth, trying various options, kernel options and so on to no avail. Then as the box was originally built on an Intel host but was currently running on an AMD host the VM was moved back to Intel. At this point both the host and the VM reported very high CPU usage. After moving back to AMD again the host reported that the VM was hardly suing any CPU untill we removed the Vmware tools and reinstalled them. So right now everything is back like it was configured before but both the performance and time syncing issues have been resolved. The only difference I see is that the vmware tools have now been configure while the VM was running on the AMD host. So perhaps all you need to do is reconfigure the Vmware tools? Perhaps upgrade to the latest version as well? Let us know if this helps, I guess this could be interesting information for the Vmware guys if it turns out to help. Regards Bram -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
