Re: [libvirt] [Qemu-devel] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0
On Wed, Aug 22, 2018 at 12:36:27PM +0200, Andrea Bolognani wrote:
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.
Of course this is not a new scenario - any time an app makes use of a new
feature exposed in libvirt there's a chance that guests using that feature
will not be migratable to older libvirt. The apps and/or administrators
deploying them, have to decide on the cost/benefit tradeoff.
I think this will have an impact on ability of apps to adopt use of the
virtio-0.9/1.0 device model variants though. Both oVirt and OpenStack
do care about live migration to older versions, at least at certain
periods in time. For example, during a live upgrade scenario,
This dovetails into Laine querying about the domain capabilities not
currently reporting info on the available device models. In the case
that migration to older verisons is needed, the dom capabilities info
won't be looked at anyway, as they don't wish to blindly use a feature
that just happens to exist in the current version.
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 :|