Timekeeping - JumpBox VM is losing time at the rate of several minutes per hour.

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.
http://vizzr.info/2007/09/13/gnewsense-xubuntu-vmware-guest-clock-loses-...
provides some info about timekeeping. The /boot/grub/menu.lst file in the JumpBox is missing the clock=pit argument. Is this the reason the JumpBox VM is losing time? Or is there something else I should try?

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,
Andrew

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):

Because of the way that timer devices in a virtual machine may fall behind real time and then 
catch up later, standard clock synchronization software such as the Windows Time Service 
(W32Time) or the Network Time Protocol (NTP) does not work well when run in a virtual 
machine. If the virtual machine is aware that it is behind real time and is already delivering timer 
interrupts at a higher rate so that the guest clock can catch up to real time, running non-VMware 
clock synchronization software inside the guest at the same time may also advance the virtual 
machine's clock, causing it to end up ahead of real time. Also, the widely varying timer interrupt 
rate of a virtual machine, as compared with real time, is likely to confuse algorithms in non- 
VMware clock synchronization software that attempt to detect the machine's exact timer 
oscillator input frequency and correct for small variations from the specified frequency. 

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.