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