[libvirt] [PATCH 4/6] qemu: Wire up disk model=virtio-{non-}transitional

Andrea Bolognani abologna at redhat.com
Wed Jan 16 14:31:49 UTC 2019


On Wed, 2019-01-16 at 12:44 +0000, Daniel P. Berrangé wrote:
> On Wed, Jan 16, 2019 at 01:29:13PM +0100, Andrea Bolognani wrote:
> > On Wed, 2019-01-16 at 11:39 +0000, Daniel P. Berrangé wrote:
> > > In the
> > > future they may add properties to, or change the defaults on, the
> > > -transitional or -non-transitional devices only, associated with
> > > new machine type versions. If libvirt forever uses the old devices,
> > > then we loose ability to take advantage of that.
> > 
> > Regardless of what libvirt ends up doing, from the QEMU user point
> > of view I think it would be very surprising if eg. virtio-blk-pci
> > plugged into a PCIe slot behaved differently from
> > virtio-blk-pci-non-transitional plugged into the very same slot, or
> > if virtio-net-pci,disable-legacy=false,disable-modern=false behaved
> > differently from virtio-net-pci-transitional regardless of the slot
> > it's plugged into, so moving away from that consistency should be a
> > non-goal IMHO.
> > 
[...]
> 
> In this message Eduardo said virtio-blk-pci,disable-legacy and
> virtio-blk-pci-non-transitional are only compatible with the
> pc-4.0 machine types and earlier. There's no compat guarantee
> of compat for future machine types:
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03762.html
> 
> If we didn't use the new QEMU device models right now, we could end
> up trapped forever. The safe futureproof approach is to always use
> the new devices models if available, and use disable-legacy for old
> QEMU versions only, which we know will have old machine types for
> which the compat guarantee is available.

Well, let's see if Eduardo is willing to reconsider the policy on
compatibility between virtio-*-pci-{,non-}transitional and plain
virtio-*-pci going forward based on the principle-of-least-surprise
rationale outlined above :)

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list