churchers / vm-bhyve

Shell based, minimal dependency bhyve manager
BSD 2-Clause "Simplified" License
828 stars 175 forks source link

FreeBSD 12.0 - version 1.3.0 - unable to load vmm.ko #322

Open KGuillemot opened 5 years ago

KGuillemot commented 5 years ago

Hello,

I have a FreeBSD 12.0 with vm-bhyve 1.2.3 installed.

When I execute the command:

root@vulture1:~ # vm switch info
------------------------
Virtual Switch: public
------------------------
  type: standard
  ident: vm-public
  vlan: -
  physical-ports: -
  bytes-in: 0 (0.000B)
  bytes-out: 0 (0.000B)

I upgraded the package from version 1.2.3 to 1.3.0, and I am now unable to execute any "vm" command:

root@vulture1:~ # vm switch info
/usr/local/sbin/vm: ERROR: unable to load vmm.ko!

Thank you for your help, the old version of vm-bhyve (1.2.3) is not available anymore in the FreeBSD repositories.

Regards,

Kevin

WanpengQian commented 5 years ago

In order to use bhyve, you have to load vmm.ko first. what is your output of kldstat? normally the output is:

root@nas:~/vm-bhyve # kldstat
Id Refs Address                Size Name
 1   46 0xffffffff80200000  243cd00 kernel
 2    1 0xffffffff8263d000     3c98 speaker.ko
 3    1 0xffffffff82641000    11c68 ipmi.ko
 4    2 0xffffffff82653000     2e18 smbus.ko
 5    1 0xffffffff82656000   3a9a10 zfs.ko
 6    2 0xffffffff82a00000     a4f0 opensolaris.ko
 7    1 0xffffffff82a0b000     2be8 coretemp.ko
 8    1 0xffffffff82c22000     81f0 tmpfs.ko
 9    1 0xffffffff82c2b000     7078 ioat.ko
10    1 0xffffffff82c33000     1800 uhid.ko
11    1 0xffffffff82c35000     23a8 ums.ko
12    1 0xffffffff82c38000   537460 vmm.ko
13    1 0xffffffff83170000      b30 nmdm.ko
14    1 0xffffffff83171000     6fb3 if_bridge.ko
15    1 0xffffffff83178000     4410 bridgestp.ko
16    1 0xffffffff8317d000     2e77 if_tap.ko

if vmm.ko is not loaded, you can try kldload vmm first, if it failed. maybe your bios is not enable virtualization? or does your CPU support virtualization?

kwinsch commented 5 years ago

If you try bhyve as a nested virtual machine in vmware Worksation, ESXi or similar, you have to pass through Intel VT-x or AMD's AMD-Vi (Hardware Virtualization). Usually these settings can be found in the CPU section of the configuration. Also note, that for networking to work correctly, that you probably have to enable "promiscuous mode" in the switch configuration, if not, the packets from outside will never reach the installed guests in bhyve.

AntoineBrunet commented 4 years ago

I have the same issue here. I can prevent the error message by manually unloading the vmm module before each call to the vm utility. It seems that vm uses kldstat with the -m flag to check if a vmm module is loaded, but on my install vmm.ko does not contains a vmm module, so the kldstat call does not find it, while it finds a vmm.ko file using the -n flag.

root@banach:~ # kldstat -m vmm -v
kldstat: can't find module vmm: No such file or directory
root@banach:~ # kldstat -n vmm.ko -v
Id Refs Address                Size Name
14    1 0xffffffff82f2b000   537420 vmm.ko (/boot/kernel/vmm.ko)
    Contains modules:
         Id Name
        546 acpi/ivhd
        545 pci/ppt

EDIT: I fixed this issue by enabling virtualization in my BIOS.

zachfi commented 4 years ago

12.0 is end of life.

dev852old commented 3 years ago

The VM command fails with error:

/usr/local/sbin/vm: ERROR: unable to load vmm.ko!

The error occurs because (at least in FreeBSD 13)

kldstat -qm vmm.ko

returns a value of 1, even if vmm.ko is already loaded.

The error is in /usr/local/lib/vm-bhyve/vm-util

-- vm-util  2020-01-24 15:43:46.495030000 -0800
+++ vm-util-new 2020-01-24 15:44:07.662656000 -0800
@@ -46,7 +46,7 @@
 #
 util::load_module(){
     local _mod="$1"
-    kldstat -qm ${_mod} >/dev/null 2>&1
+    kldstat -qn ${_mod} >/dev/null 2>&1
     if [ $? -ne 0 ]; then
         kldload ${_mod} >/dev/null 2>&1
         [ $? -eq 0 ] || util::err "unable to load ${_mod}.ko!"

I replaced the -qm with -qn, which seems to work at least as far as getting vm to start.

lxv commented 1 year ago

checking for the modname vmm like the code does now is the right thing to do. Here's an example showing that doing otherwise fails to detect VMX init failure:

root@vhost:~# kldstat
Id Refs Address               Size Name
 1    1 0xffffffff80200000 1f3e2f0 kernel

root@vhost:~# kldload vmm
vmx modinit: processor does not support desired basic capabilities module_register_init: MOD_LOAD (vmm, 0xffffffff82884580, 0) error 22

root@vhost:~# kldstat -vn vmm
Id Refs Address               Size Name
 2    1 0xffffffff82800000 53c438 vmm.ko (/boot/kernel/vmm.ko)
        Contains modules:
                 Id Name
                517 acpi/ivhd
                516 pci/amdiommu

root@vhost:~# kldstat -vm vmm
kldstat: can't find module vmm: No such file or directory