Hi Jason, Jason Ozin wrote: > And to further answer and refine my answer this is what was needed in > crontab > In case anyone is interested, this clock drift is a known issue when > virtualising BlueOnyx/Linux on VMWare or Hyper-V > > # update clock every 30 mins > 10,40 * * * * /usr/sbin/ntpdate -s -b -u pool.ntp.org > # sync hardware clock 5 mins later > 15,45 * * * * /sbin/hwclock --systohc
Hmmm, actually, the drift is not really due to VMware or Hyper-V, but rather the way that the guest OS responds to the virtualized clock. And running the ntpdate every 30 minutes is, at best, a big hammer used to make a fine adjustment. Realistically, it's not a fix at all. If you would rather fix the problem, then first determine if the clock runs fast or slow. My gut is that your guest OS has a fast clock, since that is what I have most often encountered with most modern multi-core systems (especially AMD, but also in Intel when the power-management features are BIOS enabled). The fix here is to pass the following kernel arguments: processor.max_cstate=1 clock=pmtmr divider=10 Placing those arguments into the kernel line of your grub boot file (/boot/grub/menu.lst) should compensate. Remember to add it to the top area of of the file as well (which is commented with #) so that when a new kernel is installed it will carry those arguments. That will help your guest OS actually keep time, rather than having to be beat over the head every 30 minutes and still drift. -- Chris Gebhardt VIRTBIZ Internet Services Access, Web Hosting, Colocation, Dedicated www.virtbiz.com | toll-free (866) 4 VIRTBIZ _______________________________________________ Blueonyx mailing list [email protected] http://www.blueonyx.it/mailman/listinfo/blueonyx
