Skip to content

Draft: RFC: FreeBSD/bhyve support

Roman Bogorodskiyrequested to merge
rbogorodskiy/libvirt-tck:rbogorodskiy-freebsd-support into master

This Merge Request is not for merging, but for a discussion. I'm currently trying to make libvirt-tck run against the bhyve driver. As expected, there are a few challenges, and before moving forward, I'd like to get feedback on what's the best way to address some of the issues.

I've started working on the 060-persistent-lifecycle.t test. I was able to make it pass:

(20:34) novel@lab:~/code/libvirt-tck[rbogorodskiy-freebsd-support] %> PERL5LIB=./lib perl   ./scripts/domain/060-persistent-lifecycle.t
1..9
# Defining an inactive domain config
ok 1 - defined persistent domain config
# Undefining inactive domain config
# Checking that persistent domain has gone away
ok 2 - NO_DOMAIN error raised from missing domain
# Defining inactive domain config again
ok 3 - defined persistent domain config
# Starting inactive domain config
ok 4 - running domain has an ID > 0
# Trying another domain lookup by name
ok 5 - the running domain object
ok 6 - running domain has an ID > 0
# Destroying the running domain
# Checking there is still an inactive domain config
ok 7 - the inactive domain object
ok 8 - inactive domain has an ID == -1
# Undefining the inactive domain config
ok 9 - NO_DOMAIN error raised from missing domain
(20:34) novel@lab:~/code/libvirt-tck[rbogorodskiy-freebsd-support] %>

I've come up with the following list of issues to make it work:

  • Network Filters not supported It could be solved by implementing the network filters, but realistically it's probably not going to happen soon. I guess there are at least 3 options to solve that:
    • Add a test suite config knob to skip nwfilters
    • Don't fail the test suite on non-implemented list_nwfilters
    • In the bhyve driver, add a minimal implementation which always returns 0 rules
  • Missing random device support Bhyve currently doesn't support passing devices like /dev/urandom. It does support virtio-rng, and it should not be hard to update the bhyve driver to use that, but how it should be handled on a test suite level, config knob again?
  • Missing ide device support Bhyve does not (and likely never will) support IDE devices, but supports SATA devices. Similar to the previous item, should there be a config knob? Or maybe just change default to sata?
  • Missing pty console support Bhyve does not support pty consoles. The bhyve driver currently supports the nmdm console, and bhyve also supports virtio-console and TCP socket connection which are not yet supported by the driver.
  • Firmware loader specification This is probably one of the trickiest ones. When no loader specified, the bhyve driver uses the bhyveload loader which allows to boot FreeBSD guests only. That means that any other guest OS requires specifying the BHYVE_UEFI.fd firmware (or use grub-bhyve). I see two options for that:
    • A test suite/framework configuration knob (again)
    • Change the bhyve driver to default to BHYVE_UEFI.fd. I like this option for two reasons: it makes bhyve domain XMLs more compatible with the other drivers, and also looks like a more reasonable default, because for example I don't run FreeBSD guests inside bhyve very often, so for most of my domains I have to set loader. It's a bit inconvenient that the firmware is not a part of bhyve and needs to be installed through the port, but we can make it possible to set the default firmware via the build option and allow to overide that via the bhyve driver configuration, which should provide enough flexibility to users, I guess.
  • Missing interface type="network" This probably should not an issue. I have a patch to the bhyve driver that adds support for that (hopefully I understand the semantics of that type properly).

Thanks, Roman

Merge request reports