bhyve issues on Dell C6220 node

Matt Churchyard matt.churchyard at userve.net
Thu Jan 9 10:22:57 UTC 2020


On Thu, 9 Jan 2020 at 08:37, Rodney W. Grimes <freebsd-rwg at gndrsh.dnsmgr.net<mailto:freebsd-rwg at gndrsh.dnsmgr.net>> wrote:
>
> Loading kernel...
> /boot/kernel/kernel text=0x168fdf1 data=0x1d0a68+0x768d80 syms=[0x8+0x178bc0+0x8+0x1969d5]
> Loading configured modules...
> can't find '/boot/entropy'
> /
> "
>
> I get either a "|" or "/" character, then nothing else.

My experience has been when I see this it is a "wrong console" issue, ie the kernel
has decided to use something else for a console and your output is going there.

It might be your setup using a UEFI with a fb console up to the end of the loader,
then the kernel decides it is using a serial console.  Or vice versa.

>Rod is correct.  I came across this issue in 12.0 and probably is also in 11.3 by now.  See here:  https://wiki.freebsd.org/bhyve/UEFI for some tips that may help you work out where your console is >redirecting.

>I use UEFI for all guest operating systems with a custom UEFI loader that has been fixed to handle OpenBSD (as you know :-) ).

Thanks guys.
I have managed to get FreeBSD to boot using the UEFI loader with boot_serial=no. Shame that I can’t get it to boot with bhyveload as it seems a more streamlined boot process and allowed me to easily access the main console directly from ssh.

One thing I have now noticed is that it will boot when accessing the console via an nmdm device on com1. However, if I try and boot bhyve in the foreground using stdio (I usually just run it in a tmux window as I find it far more flexible than nmdm/cu), it stops, so clearly does seem to be a console issue. I can’t however find any loader setting that will fix it.

>
> I've also tested a windows server 2016 guest, and while that will actually install via UEFI, it is noticeably slow - over a minute to boot to the login screen and everything crawls along
>

>2016 is slow (even slower doing windows updates).  2019 is much better.  A tip I have found is a minimum of 1 cpu, 2 cores and 4 threads to get decent speed from that OS (more CPUs in bhyve >tends to make performance worse - in my observations - in 2016).  Also, use the Virtio collection from RedHat for vionet and viostor.  We are currently using 0.1.171 without issue.  The ahci >emulation in itself is extremely slow.  NVMe and virtio is really the only way to go.

Is there anything else I can check here? I haven’t got round to testing networking yet but I’m using nvme for the disk.
It’s basically unusable and there is no way I could put anything production on it. Just highlighting an icon on the desktop takes several seconds.

Matt




More information about the freebsd-virtualization mailing list