I'm using Parallels 3150 and I'm having trouble keeping my FreeBSD 6.2 guest's clock correct. I'm running ntpd like I would on any of my FreeBSD systems running on hardware, but it doesn't seem to have an affect. I can run ntpdate to set the clock one time, but the drift is really bad. Thirty minutes after setting the clock with ntpdate the clock will be about 10 minutes slow. My Windows VMs all have the correct time (I assume because I have the parallels tools installed). Does anybody have a solution/workaround for this problem (even reverting to a previous parallels version)?
This is a common problem with VMs - not just Parallels but the Other People too... The solution in Linux is to change the way the clock is calulated using the "clock=pit" kernel parameter, or to re-compile the kernel with the interrupt rate reduced from 1000 to 100 Hz. I know you are asking about FreeBSD, not linux, but this might provide some clues... ntpd is designed to correct the clock gradually, to avoid a sudden jump that might upset running software (or make Neo see the same cat twice) and can not keep up with a clock that is drifting badly.
I've seen something like this w/ FBSD under VMWare, as well. The clock just starts with the last value it had when the host machine was suspended. Windows VMs seem to be right - I suspect it's because there's more effort and focus on the Windows tools than the FBSD versions. Clock updates are easy to let slip. I have to reset the FBSD clock every startup. rickb
Thanks itsdapead! I've seen the clock=pit Linux fix before, but didn't know how to translate that to FreeBSD. But the bit about changing the interrupt rate seems to help. To adjust the interrupt rate in freebsd, put this in your /boot/loader.conf: kern.hz=100 and reboot. I've been running with this configuration for 10 minutes and the clock is perfect with my OS X system (before it would have been very off).
You can also just choose the "set to my local time" option in Kontrol and that does it... if yer a GUI type. = )
That's actually a separate issue. There are two issues here: 1. the clock drifts 2. the clock doesn't update to the current time when you unsuspend To fix the clock drift problem (on Linux) use the aforementioned kernel option. As for the not updating problem, like you I haven't found a better solution than resetting the clock every time I unsuspend (or wake up my MacBook from sleep). However, I have added a shortcut to my GNOME top edge panel that I can click on to reset the clock. It runs the following command (in Linux): gksu ntpdate <an ntp server>
