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