4:21 a.m.
On Fri, Dec 17, 2021 at 09:55:56AM +0100, Laszlo Ersek wrote:
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."
There was definitely discussion about this at Red Hat. I'm not sure
what the current situation really is. But if we can make it work with
a simple change (like in this bug) then we probably ought to.
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 :)
What RHEL supports, what virt-v2v offers and what customers do are
often in conflict.
No one is using virt-v2v when they have a way to ansible-deploy their
entire cloud infrastructure of "cattle" from a single button press.
They're using virt-v2v (and even more so, virt-p2v) because they have
very special pet machines that they have no idea how to rebuild
because the sysadmin who installed it left the company / the obscure
CNC machine software isn't supported on newer OSes and the
manufacturer went out of business / they have some regulatory
requirement to use RHEL 5 / they don't want to touch that thing in the
corner which is working.
So we need to keep things going for them even if RHEL doesn't
necessarily support their use case. That means making conversions of
RHEL 5/6 work on RHEL 9, especially if it doesn't really require much
effort as in this case.
Back to this patch: after I (unknowingly) worked around
RHBZ#1942325,
manually, I managed to test the patch successfully. Can you please ACK it?
Sure, ACK to that patch, thanks!
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v