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

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).

(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)