FreeBSD 9 on ESXi 5, clock stops

scotia

Active Member

Reaction score: 11
Messages: 152

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
 

glocke

Member

Reaction score: 11
Messages: 61

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.
 

grahamb413

New Member

Reaction score: 2
Messages: 3

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
 

throAU

Aspiring Daemon

Reaction score: 149
Messages: 910

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.
 

joel@

Active Member
Developer

Reaction score: 46
Messages: 249

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.
 

xzkto

New Member

Reaction score: 1
Messages: 7

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?
 

joel@

Active Member
Developer

Reaction score: 46
Messages: 249

Did you report it to VMware? Do you have a valid support contract?
 

grahamb413

New Member

Reaction score: 2
Messages: 3

xzkto said:
Did they change that 5.1 upgrade, I missed something or grahamb413 has some different issue?

Apologies for the confusion.
It turns out that we were upgraded to a newer build and not 5.1
Now on 5.1 and the problem had not yet come back
 

spork

Active Member

Reaction score: 13
Messages: 159

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

jpierri

Member

Reaction score: 22
Messages: 57

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.
 
Top