On Wed, May 13, 2020 at 01:36:05PM -0300, Daniel Henrique Barboza wrote: > > > On 5/13/20 12:32 PM, Michal Privoznik wrote: > > On 5/13/20 4:48 PM, Daniel Henrique Barboza wrote: > > > > > > > > > On 5/12/20 11:52 AM, Michal Privoznik wrote: > > [...] > > > > I think the problem is simpler to handle in Libvirt when QEMU deprecates the old > > > format entirely. Otherwise the user will have to also keep track of Libvirt versions > > > to understand why the migration is failing here and there. > > > > I think they will have to track both actually. They will have to track QEMU version, no argument there. But also Libvirt version - they minimal required version would have to be the one where Libvirt switches from old to the new API. > > In that case, I believe that offering a XML knob to choose which NUMA mode > the user wants (like I mentioned in the previous message) is a good way to > mitigate the overall annoyance of the situation. It's simpler to add "mode='legacy'" > in the domain XML than to update Libvirt. This is something we really don't want todo, as this is supposed to be an internal impl detail. The fact that it had migration impact was accident. If we expose it as a knob, then you need to teach mgmt apps to set the knob which has a huge ripple effect through the consumers of libvirt. This is what the QEMU feature advertizement against machine type is supposed to avoid 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 :|
