On 2019-05-22 09:25, mxb wrote:
I think FreeBSD or any Linux template will work just fine and add
vmxnet3.
However, last I checked (1year ago) vmxnet3 been less stable than
e1000 under pressure.
Don't use the Linux templates. I would recommend against using the
FreeBSD templates, and go with "Other (64-bit)" instead. YMMV on using
FreeBSD vs Other, I haven't seen consistent results here yet... just
don't pick Linux, or DOS, or Windows - in some situations, that allows
VMware to take certain shortcuts that are based on assumptions about the
Linux/Win/etc. kernel & device drivers that (probably) aren't valid
under OpenBSD.
Various people have reported different problems with vmxnet3; I'm aware
of at least 4 or 5 different environment-specific issues (i.e. can't be
reproduced on any other vSphere/ESXi system). I have some of those
problems, and I cannot reproduce them outside my production environment,
but they don't prevent me from running OpenBSD.
Workarounds:
* use vmxnet2
* use e1000
If vmxnet3 and pvscsi work for you (you'll know pretty darn fast!), use
them. When they work, which is usually (in my experience), they're
generally very stable and high-performing compared to the emulated h/w
(e1000, lsisas, lsiscsi, buslogic).
I also experience timer issues, and I've had to specify
kern.timecounter.hardware=i8254 in sysctl.conf. This is likely a VMware
problem, not an OpenBSD problem, but it's non-trivial to diagnose.
(Even i8254 doesn't work perfectly: e.g. usleep() isn't very accurate in
my VMs!) I'm also running these VMs on very heavily-loaded hosts, which
is probably a factor.
My disk write throughput is horrible, but that's an interaction between
how OpenBSD does writes, how VMware handles writes into thin-provisioned
disks, and how my NFS storage handles writes on thin-provisioned
volumes; it's not an OpenBSD problem, strictly speaking, although that's
the only place it's normally visible.
Overall, OpenBSD works well under ESXi, but there are semi-random
problems that do have workarounds.
Several years ago, Theo noted (approximately, I'm going from memory here
AND paraphrasing) that it was hard enough for OpenBSD to handle broken
hardware implementations, it's exponentially harder to handle an
incorrect software emulation of hardware that was incorrect in the first
place. This has proven accurate, and VMware doesn't really care much
about OpenBSD, since I doubt it even registers on their radar so they're
not terribly interested in fixing VMware bugs that are only visible
under OpenBSD. (If you have a support contract, please submit bug
reports to VMware. If enough of us do so, they might start fixing some
of the problems.)
-Adam
