On 8/29/19 11:17 AM, Vladimir Sementsov-Ogievskiy wrote: > Aren't you going to deprecate and drop it at some moment? Libvirt's going to keep supporting older versions of QEMU in perpetuity. Apparently, there are still some barriers (SD cards?) to using only blockdev API for new versions, too: >> "Note that even with new qemu, if an SD card is used blockdev will be >> disabled." It sounds like we need to facilitate libvirt's transfer to an all-blockdev API for modern QEMU instances. Once we do that, we can likely add an introspectable feature flag to commands that create formerly-implicit nodes to tip off libvirt as to what behavior it can expect. (In practice, if libvirt sees the new flag, it knows it needs to rely exclusively on blockdev API and that (likely) it should always provide a node-name for the filter.) I think it is reasonably clear that deprecating and re-implementing is not something that will be compatible with libvirt's feature detection, so we shouldn't do it. I'm still not sold that this is worth the effort, but you and Max would know best right now. I'll leave it to you two to sort out. --js -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
