Hi, I'd like to test the bhyve driver using libvirt-tck, which seems to be very useful both from the continuous integration perspective, and making the bhyve driver closer to other drivers to improve integration with other tooling.
As a small proof-of-concept I made just a single test 060-persistent-lifecycle.t work with bhyve, though it was enough to highlight a bunch of issues. I've created a pull request on Gitlab: https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/58 but apparently it's not very active there, so I'll briefly repeat it here as well. Issues I encountered: * Network Filters not supported It could be solved by implementing the network filters (obviously), 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 * Hardcoded /dev/urandom RNG devices As the bhyve driver now supports virtio-rnd with /dev/random backend, should there be a configuration knob for libvirt-tck to override the RNG device definition? * 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(8) 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 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 override that via the bhyve driver configuration, which should provide enough flexibility to users, I guess. Any thoughts and recommendations how to tackle this project appreciated. Thanks, Roman
