9:48 a.m.
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