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
