bhyve Unable to VNC to bhyve VM - connection refused

I haven't needed efi vars under 15 to install (from an iso) or to run debian 13.
You imagine well that I won't test to find or not if a debian really needs efi vars. Fact is that all EFI VM MUST have its efi vars like a bare bone PC has. Nevertheless, I can look if debian now writes a /boot/bootx64.efi (see below).

Several people have reported that a debian bhyve VM doesn't work at reboot. And it's because debian set its own loader path/name in the ESP. It's not the default /boot/bootx64.efi. It then uses efibootmgr to set its own loader name as an efi boot var. But if you don't have an efi vars file, the VM forget it at reboot. It's as simple as that.

bhyve didn't support efi vars at some point in the past. So, copy the debian loader to /boot/bootx64.efi was mandatory. It's not anymore the case since some years.

FreeBSD does the same as debian but keeps writing /boot/bootx64.efi (if not already exists) in addition to its dedicated loader.

Concerning the Op problem, the fact that vnc can't connect shows that the VM isn't running (or bhyve has crashed). It's likely a vm-bhyve problem. It has some logs, you should look at them.
 
I have installed a Debian 13 VM in bhyve, but I get a connection refused when I try to VNC to it. In my debian.conf file that I created, I used these parameters:

graphics="yes"
graphics_res="1600x1200"
graphics_wait="auto"
xhci_mouse="yes"
loader="uefi"
cpu=”2”
memory="8G"
network0_type="virtio-net"
network0_switch="public"
disk0_type="nvme"
disk0_name="disk0.img"

The install went fine, but after rebooting the VM and trying to VNC to the VM, I get a connection refused message. The vm list command shows the State as "Locked" and the VNC header shows: 0.0.0.0:5900.

I know the problem lies with this specific VM because I have created a VM using Windows 10, and it runs fine and I can connect to it without any problem.

What am I doing wrong?

Thank you,
Ed
Have you tried using zvol instead of nvme?
 
You imagine well that I won't test to find or not if a debian really needs efi vars. Fact is that all EFI VM MUST have its efi vars like a bare bone PC has. Nevertheless, I can look if debian now writes a /boot/bootx64.efi (see below).
I can't know what you did. I was just describing my experience. I seem to recall fiddling with efi vars a couple years ago but not any more. Just now I replicated the install and reboot with 15.0-RELEASE-p5 (but with bhyve patched as described above). It does seem to populate both /boot/efi/EFI/BOOT and /boot/efi/EFI/debian dirs. The latter has a few more files and BOOTX64.EFI is renamed shimx64.efi

I used this iso: https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.4.0-amd64-netinst.iso and the following script. Earlier I had used debian-13.2.0-amd64-netinst.iso. The disk img file was created with truncate -s 32 debian.img.

sh:
/home/bakul/bin/bhyve -c 1 \
        -s 0,hostbridge \
        -s 4,ahci-cd,debian.iso \
        -s 5,nvme,debian.img \
        -s 10,virtio-net,tap2,mac=aa:bb:cc:dd:ee:ff \
        -s 20,xhci,tablet \
        -s 31,lpc \
        -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
        -s 11,fbuf,tcp=0.0.0.0:5906,w=1920,h=1080,wait \
        -l com1,/dev/nmdm6B \
        -m 4G -H \
        debian
 
Thank you all for your feedback!

The one thing I discovered is that if you use loader="uefi" and not loader="grub", you can use TigerVNC to connect for the setup and, eventual connection to your VM.

I tried another Debian setup and the setup and even boot process *almost* worked. Debian would boot, but eventually hang and never made it to the login manager. I then tried Lubuntu (https://lubuntu.me/) and voila!...that seemed to work! In my case, I need either Debian (or a Debian based variant) or CentOS flavor because we have .deb and/or .rpm packages to install in order to be able to connect to my work VPN.

My Lubuntu conf file looks like this:

graphics="yes"
graphics_port="7000"
graphics_res="1440x900"
graphics_wait="auto"
xhci_mouse="yes"
loader_timeout="10"
loader="uefi"
cpu=2
memory="8G"
network0_type="virtio-net"
network0_switch="public"
disk0_type="nvme"
disk0_name="disk0.img"
disk0_size="50G"

Now I just need to tackle and finish the whole PCI passthrough, USB thing so I can pass through my OnlyKey hardware token (https://onlykey.io/) to the new VM. I haven't tried to use it yet on the FreeBSD host, but I'm guessing it probably work work.


:)

Have a great weekend.

Ed
 
I can't know what you did. I was just describing my experience. I seem to recall fiddling with efi vars a couple years ago but not any more. Just now I replicated the install and reboot with 15.0-RELEASE-p5 (but with bhyve patched as described above). It does seem to populate both /boot/efi/EFI/BOOT and /boot/efi/EFI/debian dirs. The latter has a few more files and BOOTX64.EFI is renamed shimx64.efi
The point is that debian 13 actually set a default loader: /efi/boot/bootx64.efi
It wasn't the case with debian 12.

Debian 12:
root@debian-12:/# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 10G 0 disk
âânvme0n1p1 259:1 0 512M 0 part /boot/efi
âânvme0n1p2 259:2 0 8,5G 0 part /
âânvme0n1p3 259:3 0 976M 0 part [SWAP]
root@debian-12:/# ls /boot/efi/EFI
debian
root@debian-12:/# ls /boot/efi/EFI/debian/
BOOTX64.CSV fbx64.efi grub.cfg grubx64.efi mmx64.efi shimx64.efi

There is no directory /EFI/BOOT/ and this is where an uefi firmware will seek for a loader if no efi var is set.

Debian 13
root@debian-13:/# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 10G 0 disk
âânvme0n1p1 259:1 0 759M 0 part /boot/efi
âânvme0n1p2 259:2 0 8,7G 0 part /
âânvme0n1p3 259:3 0 548M 0 part [SWAP]
root@debian-13:/# ls /boot/efi/EFI/
BOOT debian
root@debian-13:/# ls /boot/efi/EFI/BOOT/
BOOTX64.EFI fbx64.efi grubx64.efi mmx64.efi

Here you have the default /efi/boot/bootx64.efi (among others loaders).
Note that with an efi vars file, efibootmgr report as first for boot: \EFI\debian\shimx64.efi.
 
Back
Top