Re: question about migration

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2016-01-05 at 18:17 +0000, Ian Jackson wrote:

> So any code trying to use this for your snapshotting case is already
> broken and cannot be fixed without introducing a new API (probably one
> which generates separate suspend/unsuspend events).

Remus does seem to work at least to the extent that it seems not to be
hitting this case though? Or at least I assume so since people have
reported various cases as working. Or maybe no one ever did "xl shutdown"
after checkpointing so this went unnoticed.

I'm trying to decide if this is "it's completely knackered" for "fails in
some corner cases".

> (We can't have libxl_evenable_domain_death generate new unsuspend
> events because existing callers won't understand.)

Can we make it so that the new API can be extended in this way, even if we
just document "ignore unknown events"?

> I therefore propose that:
> 
> libxl_evenable_domain_death should never generate DOMAIN_SHUTDOWN with
> reason code suspended.

FWIW libvirt ignores these (and as we know xl incorrectly exits). I guess
we think it unlikely that anything could be relying on the current
behaviour?

OOI would calling libxl_evdisable_domain_death+libxl_evenable_domain_death
reset the one-shot nature of this event?

>   Instead, it should hope that the domain will
> go back to running.  If the domain ends up shut down for some other
> reason, or is destroyed, it should report those things.
> 
> In the future we introduce libxl_evenable_domain_state which generates
> the existing events from libxl_evenable_domain_death but also two new
> events DOMAIN_SUSPENDED or DOMAIN_RUNNING.

I infer that this new function will take a mask of domain states which the
caller is interested in (and hence is extensible)?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel