FreeBSD 9 on ESXi 5, clock stops

Hi all,
I've been running 8.2 on about 10 VMs on ESXi 5 (and then 5.1) for a while now with no issue. Then I added the vmx3f (VMXNET 3) NIC to a VM, and a few days later (last night) the clock froze. As discussed, this was fixed with ACPI-safe.
Not sure if it's just a coincidence with the addition of the NIC to the VM. Just thought I'd posit the thought.
Regards
Scott
 
sysbench has been running now continuously for more than 27 hours. I issued a ntpdate after that:

Code:
25 Sep 15:05:48 ntpdate[66479]: step time server 93.185.134.36 offset 2.512522 sec

Definitely not a big difference, of course you still want to sync your clock in some way. I will try the same test on the cloned host on a ESXi 5.0 environment, but with a lower vHardware Version, this one has vmx-09, FWIW it has an em interface connected to it.
 
Unfortunately I upgraded to ESXi 5.1 running Freebsd 8.2 and had this issue come back around 2 weeks after upgrading ESXi.
ACPI-safe resolved the issue again though.
I'll post more info on the setup including the NIC types when I get a free moment
 
Have VMware confirmed whether or not this is fixed in 5.1? I just did a search for the PR on their site to see whether or not there is an equivalent 5.1 patch but no joy.
 
throAU said:
Have VMware confirmed whether or not this is fixed in 5.1? I just did a search for the PR on their site to see whether or not there is an equivalent 5.1 patch but no joy.
I'd be interested in this as well.
 
grahamb413 said:
Unfortunately I upgraded to ESXi 5.1 running Freebsd 8.2 and had this issue come back around 2 weeks after upgrading ESXi.
ACPI-safe resolved the issue again though.
I'll post more info on the setup including the NIC types when I get a free moment

joel@ said:
I've just received confirmation from VMware support that the timer fix is included in 5.1. :)

Did they change that 5.1 upgrade, I missed something or grahamb413 has some different issue?
 
Thanks to all for adding all the info to this thread, very much appreciated.

It took me way too long to figure out this was my issue today. For those running firewalls (at least pf), note that your notification you hit this bug might be that the box goes unpingable. When the clock stops, pf has no idea it should be reaping old states out of the state table. One might think they were being DDoS'd or similar as the state entries keep climbing and climbing and you see the same hosts over and over in pfctl state listings... :)
 
For those that still need to run VMware 5.0 or 5.1 (due to some compliance rule or something else), this issue still happens with 11.2-RELEASE-p11

The fix works as used to be:

sysctl kern.timecounter.hardware=ACPI-fast
date HHMM (put current time, just to kick clock back into action)


Remember to put it in /etc/sysctl to keep it fixed after the next reboot.
 
Back
Top