Re: [libvirt] [Qemu-devel] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0
On Tue, 2018-08-21 at 14:21 -0400, Laine Stump wrote:
On 08/17/2018 06:35 AM, Andrea Bolognani wrote:
> If we decide we want to explicitly spell out the options instead
> of relying on QEMU changing behavior based on the slot type, which
> is probably a good idea anyway, I think we should have
>
> virtio-0.9 => disable-legacy=no,disable-modern=no
> virtio-1.0 => disable-legacy=yes,disable-modern=no
>
> There's basically no reason to have a device legacy-only rather
> than transitional, and spelling out both options instead of only
> one of them just seems more robust.
I agree with both of those, but the counter-argument is that "virtio"
already describes a transitional device like your proposal for
virtio-0.9 (at least today), and it makes the versioned models less
orthogonal. In the end, I could go either way...
Yeah, Dan already made that argument and convinced me that we
should use virtio-0.9 for legacy only, virtio-1.0 for modern only
and plain virtio for no enforced behavior / transitional.
The problem I can see with the virtio-1.0 model name is that if
management applications start putting that into their XML (even though
"virtio" would yield a working guest), the guests will be unable to
migrate to another machine that has the same version of qemu, but an
older libvirt that doesn't understand the virtio-1.0 model number. If
that's acceptable, then management apps can being always specifying the
version for virtio whether it's old or new. If not, then they should
continue to use plain "virtio" unless they specifically need to force
virtio-0.9.
Well, even using virtio-0.9 could be considered problematic,
because at least from the QEMU point of view there's nothing
preventing the guest from working correctly as long as the version
is recent enough that disable-legacy/disable-modern are available.
AFAIK management applications such as oVirt and OpenStack usually
require specific, reasonably recent versions of QEMU and libvirt,
so they could make sure virtio-0.9 and virtio-1.0 are understood
by all nodes in the cluster that way.
For something like virt-manager where the coupling is loose
perhaps it would make sense to use virtio-0.9 only on q35 when
the OS requires it and plain virtio everywhere else for the time
being, then switch to always using virtio-0.9 and virtio-1.0
after a Reasonable Amount of Time™ has passed.
--
Andrea Bolognani / Red Hat / Virtualization