Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0
adams-freebsd at ateamsystems.com
Mon Mar 19 06:26:39 UTC 2012
On 3/12/2012 0:01, Ian Lepore wrote:
> It seems unlikely to me that ntpd and the vm tools would be fighting in
> a way that caused this symptom. The way ntpd affects timing is to step
> the clock (which gets logged), or to numerically steer the kernel's
> timekeeping routines. The steering is clamped at 500 ppm; to make the
> clock appear to stop it would have to steer at 1e6 ppm. I've always
> assumed that VM guest services daemons that handle timekeeping use the
> same ntp_adjtime() interface to the kernel timekeeping that ntpd itself
> uses, so the same steering limits would apply.
An excellent point.
> If it happens again, interesting data might be found in the output of:
> sysctl kern.timecounter
> sysctl kern.eventtimer
> vmstat -i
> ntpdc -c kerninfo
> <anything unusual in dmesg output>
Will do, I know there was nothing in dmesg, I will definitely check all
of this though if/when it happens again. I just brought up another ESXi
5.0 host with FreeBSD 9.0 VMs (created from dump/restore from the
existing ones), so there is an increased chance of me seeing this
hopefully and getting to the bottom of it. Or it never happens again :P
On 3/19/2012 1:36, Steve Wills wrote:
> I've experienced something similar once or twice with ESXi 5.0. The
> second time it happened, I found that kern.timecounter.tc.HPET.counter
> stopped changing. I was told on IRC that this indicated a "hardware"
> problem, which I took to indicate a possible bug in ESXi. I haven't
> upgraded to ESXi 5.0 Update 1 yet to see if that changes anything.
> Rebooting of course fixed it, it has been a while since this happened
> and it hasn't happened again since so I haven't pursued it. Just another
> data point, hope it hopes.
Thanks for the info! I didn't realize there was an update out already
for 5.0 (I don't see it on VMWare's site).
More information about the freebsd-stable