Hmmm... that's an odd one.
For the original OpenBSD crash, could you possibly locate the vmware*.log file inside the VM bundle which contains the crash information, and provide that here as an attachment?
I am curious as to how you were able to launch Terminal.app (and the shell within it) if the host's process table is full... I think there is more to this than just a full process table, but I don't quite know yet what it could be. Are you able to launch other apps besides Terminal and VMware Fusion? Maybe LaunchServices is just confused about whether or not Fusion is still running...?
Are you able to collect a support information bundle after rebooting the host? (i.e. Is it the crash of the OpenBSD VM which puts your host into a state where the support information tool fails?)
If you are willing to put your system into the failing state again, but I'd be interested to know if you could run a "ps auxww" at the Terminal window afterwards, so that we can see which processes are actually running.
I was not able to collect a support bundle at all. (The tgz file never showed on the desktop.)
However, I was able to collect three log files from the VM bundle which I have attached.
I saw "PANIC: VERIFY bora/devices/vmxnet3/vmxnet3_hosted.c:831" in vmx log, did you configure a customized virtual network vmxnet3? If yes, what is your configuration on vmxnet3?
Here are the relevant lines from the VMX file:
ethernet0.present = "TRUE"
ethernet0.connectionType = "bridged"
ethernet0.virtualDev = "vmxnet3"
ethernet0.wakeOnPcktRcv = "FALSE"
ethernet0.addressType = "generated"
ethernet0.linkStatePropagation.enable = "TRUE"
ethernet0.pciSlotNumber = "160"
ethernet0.generatedAddress = "00:0c:29:e1:5e:4a"
ethernet0.generatedAddressOffset = "0"
ethernet1.present = "TRUE"
ethernet1.connectionType = "hostonly"
ethernet1.virtualDev = "vmxnet3"
ethernet1.wakeOnPcktRcv = "FALSE"
ethernet1.addressType = "static"
ethernet1.address = "00:50:56:3C:61:4A"
ethernet1.pciSlotNumber = "192"