[libvirt] [Qemu-devel] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0

Daniel P. Berrangé berrange at redhat.com
Wed Aug 22 15:01:55 UTC 2018


On Wed, Aug 22, 2018 at 10:37:12AM -0400, Laine Stump wrote:
> On 08/22/2018 09:44 AM, Daniel P. Berrangé wrote:
> > Even if someone is willing to implement it in libvirt, we have to
> > consider the cost of supporting it in both libvirt and applications
> > using libvirt and the complexity it adds to our story about the
> > docs / best practices for configuring guests.
> >
> > Even though I do kind of like the virtio-0.9/virtio-1.0 device model
> > as concepts, I'm yet to be convinced that implementing them in libvirt
> > and then also in all the downstream applications (oVirt, OpenStack,
> > virt-manager, cockpit, etc) is actually worth the cost.
> 
> I'm starting to lean towards this opinion too - I was thinking about
> this over the weekend, and it does seem like the code in the management
> apps will be convoluted/complex/your favorite adjective. Going into this
> I had the naive impression that a simple bit of logic in the management
> application could just take the union of supported devices from
> libosinfo(guestOS) and domaincapabilities(qemu), then pick the top model
> name from the list. It's unfortunately not that simple, so we're going
> to end up with a bunch of extra code in the management application
> (multiplied by the number of management apps, multiplied by the number
> of different virtio devices) and that code will need to be maintained.
> 
> In the meantime, the only advantages over just giving up and using 440fx
> for RHEL6 would be 1) consistent support for using Q35 on all
> "supported" guest OSes, 2) the possibility of doing SecureBoot, and 2)
> being able to someday in the future eliminate all 440fx-specific code
> from the set of code that needs to be tested/maintained by downstream
> maintainers. (1) is nice and clean, but the value is dubious if it's
> achieved by "unclean" code elsewhere. (2) is a non-feature for almost
> everyone, and (3) isn't going to happen anyway, since any existing
> guests have already been setup using 440fx as the machinetype, and we
> can't force people to change the machinetype of an existing guest (as
> Dan says, over the amount of time needed to make that an acceptable
> requirement, the guest OSes in question could likely reach EOL anyway).

Two notes

 - The notion of "supported" guest OS is an invention of downstream
   distro vendors.

 - RHEL-6 doesn't support SecureBoot at all, even on bare metal.
   IOW the possibility of SecureBoot with KVM for RHEL-6 doesn't
   even arise to begin with.

> (NB: of course if we want to require 440fx for RHEL6, we'll still need
> to do the work on libosinfo to report "supported machinetype", and on
> all the management applications to honor that information)

Yes, we still have plenty of work todo across the mgmt apps just to get
Q35 used by default in the first place.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list