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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
