Libguestfs - Dec 2021 - [v2v PATCH v2] convert_linux: translate the first CD-ROM's references in boot conf files

On Thu, Dec 16, 2021 at 05:53:11PM +0100, Laszlo Ersek
wrote:
> Summary: libosinfo should have told virt-v2v that RHEL-5.11 does not
> have virtio-1.0 drivers, only virtio-0.9 drivers. Accordingly, virt-v2v
> should have generated "virtio-transitional" model attributes, so
that
> libvirtd would position the virtio devices in traditional PCI bus slots.
> 
> Do we need a new BZ about this?
Isn't it this one (albeit the title should be <= 6):

https://bugzilla.redhat.com/show_bug.cgi?id=1942325


Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

On 12/16/21 18:32, Richard W.M. Jones wrote:
> On Thu, Dec 16, 2021 at 05:53:11PM +0100, Laszlo Ersek wrote:
>> Summary: libosinfo should have told virt-v2v that RHEL-5.11 does not
>> have virtio-1.0 drivers, only virtio-0.9 drivers. Accordingly, virt-v2v
>> should have generated "virtio-transitional" model attributes,
so that
>> libvirtd would position the virtio devices in traditional PCI bus
slots.
>>
>> Do we need a new BZ about this?
> 
> Isn't it this one (albeit the title should be <= 6):
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1942325
Yes, that's it exactly!

Comment 3 in the BZ touches on a question that I've had in mind myself, BTW:

"BTW, rhel6 guest is not supported on rhel9 any more."

I'm a bit confused as to how far back in time we plan to support guest
OSes, and exactly how. Some example thoughts:

- If we decide that we want to drop conversion support (even up-stream)
up to and including RHEL6, then the virtio-transitional question falls
away -- and *with it*, the very patch in this whole thread. :)

- From commit ac39fa292c31 ("v2v: Set machine type explicitly for
outputs which support it (RHBZ#1581428).", 2020-12-04), we have the
following comment:

+    (* Pivot on the year 2007.  Any Linux distro from earlier than
+     * 2007 should use i440fx, anything 2007 or newer should use q35.
+     * XXX Look up this information in libosinfo in future.
+     *)

In case we pivoted -- based on any factor really -- such that RHEL5
ended up associated with the i440fx machine type, then it would not be
affected by the virtio-transitional problem at all.

I *think* that the motivation for using Q35 at all, even for guest OSes
like RHEL5 and RHEL6, is motivated by RHEL downstream. (Upstream QEMU is
unlikely to ever remove i440fx, in my opinion.) However, if we consider
RHEL downstream a guiding principle, then we should also consider that
RHEL6 (and earlier) are not supported on RHEL9+ hosts at all!

So, while I'm admittedly confused, I feel like we're trying to fill a
gap here that nobody really cares about. Personally I'd just keep RHEL5
and RHEL6 guests on i440fx, upstream, sidestepping the whole
virtio-transitional problem, and allow RHEL9 hosts to forget about these
guests in peace.

Please enlighten me :)

Back to this patch: after I (unknowingly) worked around RHBZ#1942325,
manually, I managed to test the patch successfully. Can you please ACK it?

Thanks,
Laszlo