* Yury Kotov (yury-ko...@yandex-team.ru) wrote: > 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.
Actually it doesn't - you just add a property, default it to true and then add an entry in hw_compat_4_1 to turn it off for older types. > If you don't mind, I suggest to keep the current version. That's OK. Dave > > > > 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 -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
