Daniel P. Berrangé wrote:
I imagine that this is a valid configuration for qemu and probably other drivers, but not for bhyve, because it doesn't support direct kernel boot (neither for Linux nor FreeBSD). However, I wasn't able to find anything similar in the driver's capabilities. If I'm not missing anything, should drivers be able to advertise whether they support direct kernel boot?
Yeah, we ought to come up with a way to express whether a driver can do direct kernel boot or not. Only virt tech that originated in a Linux context can typically do this (Xen, UserModeLinux, QEMU).
At the same time though, for the TCK we could fudge it via the configuration file. We currently list the kernel+initrd in that config file, but we could make it accept an ISO image instead perhaps ?
I'll play around with the idea of using the TCK configuration file for that. I image it'll require some fiddling with the fullos argument inside TCK, will see how it turns out.
Second example is pretty similar, but without the direct kernel bits:
<domain type="bhyve"> <name>tck</name> <memory>1048576</memory> <currentMemory>1048576</currentMemory> <os> <type arch="x86_64">hvm</type> <boot dev="hd" /> </os> <features> <acpi /> <apic /> </features> <devices> <disk type="file"> <driver /> <source file="/var/lib/libvirt-tck/libvirt-tck/os-x86_64-hvm/disk-fedora-40.img" /> <target dev="vda" /> </disk> <rng model="virtio"> <backend model="random" /> </rng> </devices> </domain>
I imagine a config like is valid for qemu and many other drivers, but it's valid for bhyve iff disk-fedora-40.img is a FreeBSD image. I think in this should not be solved on the driver's capabilities reporting level, because adding os_name details is probably way to specific.
I'm not sure I understand what the problem is in this example ? Are you saying that bhyve can only run FreeBSD guests, not Linux guests, or am I mis-interpreting ?
Not exactly. You're right that bhyveload(8) is somewhat a replacement for grub2 or similar, with a limitation that it only supports FreeBSD guests. Currently, there are two main scenarios for bhyve: * No loader/firmware configured -> defaults to bhyveload(8) and, thus, to FreeBSD guests only (just like in the example above) * <os firmware='efi'> specified -> any reasonable guest supported by the firmware is supported The problem I see here is that currently the bhyve driver defaults to a less flexible configuration with bhyveload rather than to the efi firmware. I can of course configure TCK to test against FreeBSD guests, but I was wondering whether it makes sense to switch defaults, that is, default to the efi firmware instead of bhyveload(8) when no specific loader configuration was provided? Thanks, Roman