Re: [Qemu-devel] QEMU/KVM migration backwards compatibility broken?

[Dr. David Alan Gilbert]

* Liran Alon (address@hidden) wrote:
> 
> > On 6 Jun 2019, at 16:31, Dr. David Alan Gilbert <address@hidden> wrote:
> > 
> >>> 
> >>> So we still need to tie subsections to machine types; that way
> >>> you don't send them to old qemu's and there for you don't have the
> >>> problem of the qemu receiving something it doesn't know.
> >> 
> >> I agree that if there is no way to skip a VMState subsection in the 
> >> stream, then we must
> >> have a way to specify to source QEMU to prevent sending this subsection to 
> >> destination…
> >> 
> >> I would suggest though that instead of having a flag tied to machine-type, 
> >> we will have a QMP command
> >> that can specify names of subsections we explicitly wish to be skipped 
> >> sending to destination even if their .needed() method returns true.
> > 
> > I don't like the thought of generically going behind the devices back;
> > it's pretty rare to have to do this, so adding a qmp command to tweak
> > properties that we've already got seems to make more sense to me.
> > 
> >> This seems like a more explicit approach and doesn’t come with the 
> >> down-side of forever not migrating this VMState subsection
> > Dave
> 
> If I understand you correctly, this is what you propose:
> 1) Have a .post_load() method for VMState subsections that depend on kernel 
> capability to fail migration in case capability do not exist.

Yes (wehther it fails or prints a warning depends on how significant the
capability is; if it's a guest crash then fail is probably best).

> 2) For specific problematic VMState subsections, add property such that it’s 
> .needed() method will return false in case the property is set to false 
> (value is true by default).
> 3) Have a QMP command that allows dynamically changing the value of these 
> properties.
> 4) Properties values are still tied to machine-type? I think not right?

Property values are initialised from the machine type; in your case
where you want to upgrade to use a new feature then you can use
(3) to change it.

> I instead propose the following:
> 1) Same as (1) above.
> 2) Add a MigrationParameter (and matching MigrationCapability) named 
> “avoid_state” that specifies list of subsection names to avoid sending in 
> migration even if their .needed() method will return false. i.e. We will 
> modify migration/vmstate.c to not even call .needed() method of such 
> subsection.
> 
> I believe the second proposal have the following advantages:
> 1) Less error-prone: .needed() methods are written only once and don’t need 
> to take into account additional properties when calculating if they are 
> required or not. Just depend on guest state.
> 2) Generic: We don’t require additional patch to add a new property to 
> support avoiding sending some subsection in case it doesn’t matter for some 
> workload. As we have discovered only late after msr_smi_count was added (by 
> me) at that point. Second approach allows avoid sending any subsection that 
> is deemed not important to guest workload by migration admin.
> 3) Not tied to machine-type: Properties are usually tied to machine-type as 
> they need to remain same forever for the lifetime of the guest. However, 
> migration parameters are per-migration and are meant to be tweaked and 
> changed. This allows a guest that used to run on old QEMU and moved to new 
> QEMU to now have better state saved for it’s next future migrations.
> 
> Currently we indeed have very rare cases like this ([git grep \"x-migrate | 
> wc -l] product only 4 results…) but I’m not sure it’s not only because we 
> haven’t analysed carefully the case of
> restored properties that it’s property depend on kernel capability.
> 
> As a start thought, we can start by at least agreeing to implement (1) and 
> consider the property VS MigrationParameter discussion for a later time.
> 
> What do you think?

I still don't like exposing a list of migration subsections into an
interface.

Dave

> -Liran
> 
> 
> 
> 
> 
> 
> 
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK