Re: -only-migrate and the two different uses of migration blockers

[Juan Quintela]

Markus Armbruster <armbru@redhat.com> wrote:
> We appear to use migration blockers in two ways:
>
> (1) Prevent migration for an indefinite time, typically due to use of
> some feature that isn't compatible with migration.
>
> (2) Delay migration for a short time.
>
> Option -only-migrate is designed for (1).  It interferes with (2).
>
> Example for (1): device "x-pci-proxy-dev" doesn't support migration.  It
> adds a migration blocker on realize, and deletes it on unrealize.  With
> -only-migrate, device realize fails.  Works as designed.
>
> Example for (2): spapr_mce_req_event() makes an effort to prevent
> migration degrate the reporting of FWNMIs.  It adds a migration blocker
> when it receives one, and deletes it when it's done handling it.  This
> is a best effort; if migration is already in progress by the time FWNMI
> is received, we simply carry on, and that's okay.  However, option
> -only-migrate sabotages the best effort entirely.
>
> While this isn't exactly terrible, it may be a weakness in our thinking
> and our infrastructure.  I'm bringing it up so the people in charge are
> aware :)

Hi

On the past, we have talked about this (but done nothing).

What we "thought" was to change save_complete() to just return the
equivalent of -EAGAIN, i.e. right now it is not a good time for doing a
migration, wait a little while and try again.

There is no code for that.

Fixing this will also help with latency issues.  When we move to the
complation stage, we have the equivalent of a sync in the block layer.
that can take a long time, but we don't have a way to timeout and get
back to normal migration and try it a bit later.

Later, Juan.