VMware and 8.4 known issues?

Mark Saad nonesuch at longcount.org
Tue Sep 9 22:22:13 UTC 2014



> On Sep 9, 2014, at 2:56 PM, Charles Sprickman <spork at bway.net> wrote:
> 
> Hello,
> 
> I have about a dozen FreeBSD 8.4 VMs running on a pair of ESXi
> (5.0.0, build 469512) boxes.  Generally, I have not had any problems
> with this configuration.  However one particular VM, which is
> running the same kernel and same VMware settings as the other VMs
> has paniced twice in the past few months.
> 
> I do not have a core dump, but both times a message regading the
> CD-ROM device was logged shortly before the panic:
> 
> Sep 9 08:50:56 shellvm kernel: ata1: WARNING - READ_TOC read data
> overrun 18>12
> 
> Prior to the panic, the only thing Ive observed via my normal nagios
> checks was that snmp and other network services became unavailable
> and ping times to the host became very erratic, jumping from a few
> ms to 800ms+.  After the panic, the VM is locked up hard and
> consuming copious amounts of CPU.
> 
> Looking around I see two things of note:
> 
> https://communities.vmware.com/message/1876880 (suggests it’s an
> issue with FreeBSDs CD-ROM handling)
> 
> http://freebsd.1045724.n5.nabble.com/Re-kern-150186-parallels-panic-Parallels-Desktop-CDROM-disconnected-leads-to-panic-eventually-td4114484.html
> (also suggests CD issues)
> 

I dropped the CDROM as it's also caused a weird issues were sysinstall would not find any daN devices if both were present . This was only an issue when using sysinstall to jumpstart a box. 


> This thread also ends with Ivan Voras stating "I'd say it's 'well
> known' - at least the panic also happens on VMWare, and has been
> happening for many years.
> 
> Ill try the suggested fix of completely removing the CD-ROM device
> (its currently in the device list, but is not connected), but Im
> curious if theres any reference Ive missed regarding known VMware
> issues and/or best practices.  Ill be sure to grab a console
> screenshot if it happens again, I have little hope of getting a dump
> though, as it seems the whole IO system is locked up.
> 
> Thanks,
> 
> Charles
> 

Also try to set the event timer to acpi-fast or acpi-safe . It's a sysctl named something like kern.timecounter.choice . There is a buggy emulated hpet in some versions on esxi that kill the clock on FreeBSD and Linux . There is a kb on how to fix the issue dr Linux boxes circa 2011 . 
 
--
Mark saad | mark.saad at longcount.org 

> -- Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best
> Internet www.bway.net spork at bway.net - 212.982.9800
> 


More information about the freebsd-stable mailing list