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

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

[Eduardo Habkost]

On Wed, Jan 16, 2019 at 02:37:22PM +0000, Daniel P. Berrangé wrote:
> On Wed, Jan 16, 2019 at 03:31:49PM +0100, Andrea Bolognani wrote:
> > 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 :)
> 
> I think we should use the new devices no matter what. Libvirt generally
> always strives to follow the latest QEMU best practice, even when new &
> old way of doing something are functionally identical. Eventually we
> would drop support for QEU < 4.0 and the old way would go away entirely.

It would also allow us to deprecate the old devices, which would
be welcome.  Always using the new devices when available would be
my recommendation.

But I don't want to create unnecessary obstacles for libvirt, so
if there's a real benefit in promising compatibility between both
device types, we can still promise that on the QEMU side.
Breaking compatibility on purpose is very unlikely, and the most
likely accidents could be detected by
tests/acceptance/virtio_version.py.

-- 
Eduardo

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

[Daniel P. Berrangé]

On Wed, Jan 16, 2019 at 12:45:43PM -0200, Eduardo Habkost wrote:
> On Wed, Jan 16, 2019 at 02:37:22PM +0000, Daniel P. Berrangé wrote:
> > On Wed, Jan 16, 2019 at 03:31:49PM +0100, Andrea Bolognani wrote:
> > > 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 :)
> > 
> > I think we should use the new devices no matter what. Libvirt generally
> > always strives to follow the latest QEMU best practice, even when new &
> > old way of doing something are functionally identical. Eventually we
> > would drop support for QEU < 4.0 and the old way would go away entirely.
> 
> It would also allow us to deprecate the old devices, which would
> be welcome.  Always using the new devices when available would be
> my recommendation.

I don't really see QEMU upstream deprecating the old devices any
time. There is sooooo much documentation that refers to them that
will never be fixed. 99% of users won't get any benefit from using
the new devices either, so there's no compelling reason to update
their existing configs or docs. They're not going to be a huge maint
burden to QEMU devs either given its just a toggle of a few props.

I might see a downstream distro deprecating them at some point
though, since they have a much tighter controlled usage scenario
than upstream.

> But I don't want to create unnecessary obstacles for libvirt, so
> if there's a real benefit in promising compatibility between both
> device types, we can still promise that on the QEMU side.

I don't think there's an obstacle for libvirt, as I don't see any
compelling reason to avoid the new devices when we have QEMU >= 4.0.

> Breaking compatibility on purpose is very unlikely, and the most
> likely accidents could be detected by
> tests/acceptance/virtio_version.py.

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

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

[Andrea Bolognani]

On Wed, 2019-01-16 at 15:40 +0000, Daniel P. Berrangé wrote:
> On Wed, Jan 16, 2019 at 12:45:43PM -0200, Eduardo Habkost wrote:
> > But I don't want to create unnecessary obstacles for libvirt, so
> > if there's a real benefit in promising compatibility between both
> > device types, we can still promise that on the QEMU side.
> 
> I don't think there's an obstacle for libvirt, as I don't see any
> compelling reason to avoid the new devices when we have QEMU >= 4.0.

Alright, let's do it that way then.

I still think it's important to maintain the relationship between
old and new devices consistent going forward, because not doing so
will certainly result in confusion for those using QEMU directly.

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Eduardo Habkost]

On Wed, Jan 16, 2019 at 05:24:02PM +0100, Andrea Bolognani wrote:
> On Wed, 2019-01-16 at 15:40 +0000, Daniel P. Berrangé wrote:
> > On Wed, Jan 16, 2019 at 12:45:43PM -0200, Eduardo Habkost wrote:
> > > But I don't want to create unnecessary obstacles for libvirt, so
> > > if there's a real benefit in promising compatibility between both
> > > device types, we can still promise that on the QEMU side.
> > 
> > I don't think there's an obstacle for libvirt, as I don't see any
> > compelling reason to avoid the new devices when we have QEMU >= 4.0.
> 
> Alright, let's do it that way then.
> 
> I still think it's important to maintain the relationship between
> old and new devices consistent going forward, because not doing so
> will certainly result in confusion for those using QEMU directly.

Agreed that it's a good thing to have.  I will extend the
existing virtio_version.py test case to be more strict and try to
catch mistakes that would break compatibility between the two
device types in the future.

-- 
Eduardo