[libvirt] [RFC v2 1/2] qemu_migration: don't allow ABI changes for persistent migration

[Andrea Bolognani]

On Wed, 2017-03-08 at 09:22 +0100, Peter Krempa wrote:
> On Tue, Mar 07, 2017 at 18:45:23 +0100, Pavel Hrdina wrote:
> > 
> > So far there is probably no change that is allowed to be done
> > by the VIR_DOMAIN_DEF_PARSE_ABI_UPDATE flag that would break
> > guest ABI but this may change in the future.
> > 
> > The other cases where this flag is used is only when we are
> > defining new domain or adding new device into a domain.
> > 
> > Signed-off-by: Pavel Hrdina <phrdina at redhat.com>
> > ---
> > 
> > This patch is a product of a discussion about the last patch in v1 [1].
> > Currently we allow ABI changes for persistent migration however it might
> > be something that user don't expect to be done.
> > 
> > Technically it defines new domain on the destination which would fall
> > into the same category as defining new domain from scratch without
> > migration but it may be unexpected behavior because for live migration
> > we don't allow ABI changes (for obvious reasons).
> > 
> > At first I though that this is correct and we are doing the right thing,
> > but now I'm not so sure about that and IMHO it would be probably better
> > to not do ABI updates in this case like we don't do if libvirtd is
> > restarted (for example because of an update) and also it would be
> > consistent with the live migration.
> 
> This flag was invented so that libvirt could finally properly track the
> total memory size of the VM when NUMA is used. Prior to that the
> individual node sizes would not have to total up to the size declared in
> the <memory> element. While migrating a live VM we can't change this but
> other code expects that the size is correct.
> 
> This patch would break this particular case. In general I'm not against
> a change, but the recalculation of the memory sizes should not be
> broken.

I see.

However, as it is now, we're granting blanket permission
to update the guest ABI in whatever random way during a
persistent migration, which at least to me feels like it's
way too broad.

Can we maybe introduce a less coarse-grained flag just for
the memory update, and leave the broader ABI_UPDATE for
cases such as defining an entirely new guest or attaching
an entirely new device, eg. situations where any change we
perform won't affect the existing guest? Or is it too late
for that?

-- 
Andrea Bolognani / Red Hat / Virtualization