On Tue, Apr 03, 2018 at 05:29:52PM +0200, Andrea Bolognani wrote: > On Tue, 2018-04-03 at 15:59 +0100, Daniel P. Berrangé wrote: > > On Tue, Apr 03, 2018 at 04:43:41PM +0200, Andrea Bolognani wrote: > > > Most of the compelling features introduced by any libvirt release > > > require the corresponding QEMU feature to be available. And, as > > > I've argued elsewhere in the thread, replacing the vendor QEMU and > > > libvirt with recent upstream releases is much easier than replacing > > > other components of the OS, most notably the kernel (and hence KVM). > > > > There are plenty of features we introduce that don't require new software > > versions. They may not be as frequent, but there are still compelling. > > How many of those would be compelling enough to convince users to > step outside of the comfort zone (and probably support terms) of > vendor-provided packages and roll their own virtualization stack > from upstream sources? I reckon not that many. But if you add a > newer QEMU to the mix, then that's a wholly different value > proposition. The introduction of virtlogd was one such feature that was compelling to upgrade libvirt for without any change in QEMU, as it fixed a long term security problem in libvirt. 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
