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

Andrea Bolognani abologna at redhat.com
Wed Jan 16 12:29:13 UTC 2019


On Wed, 2019-01-16 at 11:39 +0000, Daniel P. Berrangé wrote:
> On Wed, Jan 16, 2019 at 12:31:04PM +0100, Andrea Bolognani wrote:
> > On Tue, 2019-01-15 at 16:56 +0000, Daniel P. Berrangé wrote:
> > > A transitional device is 100% identical to the existing device
> > > types, so we can simply not add the "-transitional" suffix for
> > > old QEMU. The only difference is the way libvirt does PCI bus
> > > placement of the transitional device - we'd never use PCIe.
> > > 
> > > A non-transitional device is identical to the existing device
> > > types, but with  disable-legacy=true set.
> > 
> > Again, the relationship between existing and new devices is not
> > quite this straighforward because of the reasons I outlined in
> > 
> >   https://www.redhat.com/archives/libvir-list/2019-January/msg00514.html
> 
> When told to use virtio-transitional for a device, libvirt would
> only plug it into a PCI slot, never a PCI-X slot. Given this
> constraint, it is functionally identical / interchangable with
> the existing device.

Right, but you didn't spell out the constraint the first time
around, thus making your (broader) statement that a "transitional
device is 100% identical to the existing device" incorrect :)

> > But the idea of using disable-{legacy,modern} instead of the new
> > virtio-*-{non,}-transitional devices is one I had already suggested
> > in
> > 
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1614127
> > 
> > so I'm obviously on board with it :)
> > 
> > > QEMU guarantees this compatibility of the different devices,
> > > but only for machine types < pc-i440fx-4.0.0 / pc-q35-4.0.0.
> > > So we should none the less make sure we use the modern device
> > > names for any QEMU which genuinely supports them.
> > 
> > As I already mentioned in the bug report linked above, I'm not
> > quite convinced that's the case, and I don't see why we wouldn't
> > just use the options and basically ignore the QEMU-level devices,
> > as the former approach would work on old QEMU releases as well as
> > recent ones with no drawback I can think of.
> 
> The QEMU maintainers were against the idea of us doing that.

I don't recall any QEMU developer specifically saying that, but
that might be just a case of my memory sucking :) CC'ing Eduardo
so he can weigh in.

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

> Indeed if QEMU maintainers wanted us to use the disable-legacy/modern
> features long term, there would be no point in them even adding the
> new device types in the first place.

Yeah, after commenting on the bug report mentioned above I indeed
started thinking that we could have gotten away with not adding
those devices. They might still be useful to people running QEMU
directly, though.

> We should only ever use the disable- flags if the new devices do
> not exist in QEMU.

Wouldn't that potentially cause issues when migrating from QEMU
< 4.0.0, where we'd use disable-*, to QEMU >= 4.0.0, where we'd
use *-{,non}transitional instead? I guess not if the changes in
device behavior are gated by the machine type version.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list