03.09.2019, 14:25, "Dr. David Alan Gilbert" <dgilb...@redhat.com>: > * Eric Blake (ebl...@redhat.com) wrote: >> On 8/27/19 10:36 AM, Yury Kotov wrote: >> > 27.08.2019, 17:02, "Eric Blake" <ebl...@redhat.com>: >> >> On 8/27/19 7:02 AM, Yury Kotov wrote: >> >>> This capability realizes simple source validation by UUID. >> >>> It's useful for live migration between hosts. >> >>> >> >> >> >> >> Any reason why this is marked experimental? It seems useful enough that >> >> we could probably just add it as a fully-supported feature (dropping the >> >> x- prefix) - but I'll leave that up to the migration maintainers. >> >> >> > >> > I thought that all new capabilities have x- prefix... May be it's really >> > unnecessary here, I'm not sure. >> >> New features that need some testing or possible changes to behavior need >> x- to mark them as experimental, so we can make those changes without >> worrying about breaking back-compat. But new features that are outright >> useful and presumably in their final form, with no further >> experimentation needed, can skip going through an x- phase. >> >> > >> >> In fact, do we even need this to be a tunable feature? Why not just >> >> always enable it? As long as the UUID is sent in a way that new->old >> >> doesn't break the old qemu from receiving the migration stream, and that >> >> old->new copes with UUID being absent, then new->new will always benefit >> >> from the additional safety check. >> >> >> > >> > In such case we couldn't migrate from e.g. 4.2 to 3.1 >> >> I don't know the migration format enough to know if there is a way for >> 4.2 to unconditionally send a UUID as a subsection such that a receiving >> 3.1 will ignore the unknown subsection. If so, then you don't need a >> knob; if not, then you need something to say whether sending the >> subsection is safe (perhaps default on in new machine types, but default >> off for machine types that might still be migrated back to 3.1). That's >> where I'm hoping the migration experts will chime in. > > Right; the migration format can't ignore chunks of data; so it does need > to know somehow; the choice is either a capability or wiring it to the > machine type; my preference is to wire it to the machine type; the > arguments are: > a) Machine type > Pro: libvirt doesn't need to do anything > Con: It doesn't protect old machine types > It's not really part of the guest state > > b) Capability > Pro: Works on all machine types > Con: Libvirt needs to enable it > > So, no strong preference but I think I prefer (a).
IIUC the (a) option requires to add a piece of code to every machine type. This is much more complicated than adding a capability. If you don't mind, I suggest to keep the current version. > > Dave > >> -- >> Eric Blake, Principal Software Engineer >> Red Hat, Inc. +1-919-301-3226 >> Virtualization: qemu.org | libvirt.org > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK Regards, Yury
