Timekeeping - JumpBox VM is losing time at the rate of several minutes per hour.Submitted by poushag on Tue, 02/19/2008 - 10:07am.I found this morning that the Mantis JumpBox VM had a time offset of over 21,000 seconds (aka more than 5 hours). This was a very unpleasant surprise since we need accurate timestamps for each action on an issue. I went in through SSH and I was able to run ntpdate to set the clock, but this is not acceptable for ongoing timekeeping. Especially since the system has already fallen 3 minutes behind in the hour since I ran ntpdate to sync the clock. It appears that VMWare Tools is already be installed in the VM, and its time sync function (vmware-guestd) is running but it appears that it must not have been working right since the system clock had such a large offset. I would also like to suggest that you include ntpd with your JumpBoxes and give the administrator a GUI option to enable/disable the daemon and configure an ntp server if desired. Perhaps a picklist of the NIST servers (with default to one of these) and an option to select "other" and type in one's own server would be appropriate. Regards, |
Search |
Timekeeping
The Timekeeping issue is a very large issue with lots of things to consider for a JumpBox since we support over 5 platforms with the same image. We have lots of experience with dealing with this and unfortunately, no single solution will completely satisfy every customer or every platform. Our users experiences have varied dramatically even using the same exact virtualization platforms and host OSes.
Since you are a VMWare user you may want to read this if you really want to know VMWare's story: http://www.vmware.com/pdf/vmware_timekeeping.pdf
I would suggest for you, to either use NTPD or set up a cron job that runs ntpdate periodically. The reason I don't necessarily suggest running is summarized in the above document (and other NTP in virtualization related discussions on the net):
Using NTPD in your case would probably be a dramatic improvement since you are drifting so much. I have been testing ntpd in our lab here and it appears to work for me in VMWare but my clocks aren't drifting nearly as much as yours when I leave them alone (5-10min/month on Linux host using VMWare server). It probably doesn't result in native ntp accuracy but its probably good enough for most time sensitive uses (including kerberos). If you are uneasy about inefficiencies or potential problems do an hourly (give or take) cronjob that runs ntpdate.
I have been uncertain which method to choose for production JumpBoxes so far, so any user feedback is greatly appreciated.
Austin
Suggestion:
The difficulty in keeping time under VMWare I think could have been avoided if the vmx file for the VM had set the variable tools.synctime = "TRUE". Since you all took the trouble to install VMWare Tools in the guest VM, I don't understand why that variable would be set to FALSE. I realize that this variable value could probably be reset by the user (although I'm not sure our VMWare Server even recognizes that VMWare Tools are installed on the Mantis JumpBox VM already). But, in any case, I think that it would be better to deliver a system that keeps time correctly from the start and I don't see how setting that variable to TRUE could do anything but help.
Time
That value is supposed to be set to TRUE on all JumpBoxes at this point. This has been the case since about November. I have verified that the shipped config file is incorrect. Thanks for pointing this out. You are absolutely right.
Austin