Re: [Xen-devel] question about migration

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/01/16 15:40, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] question about migration"):
>> On 04/01/16 17:46, Ian Jackson wrote:
>>> Suppose a domain goes into SHUTDOWN with reason code SUSPEND.  Then
>>> later it is resumed again (perhaps the migration failed).  And later
>>> it shuts down cleanly.
>>>
>>> Will this generate a second @releaseDomain ?  How is a toolstack
>>> supposed to discover this situation ?
>> By the looks of it in Xen, domain_resume() sets d->is_shut_down = 0,
>> which means a subsequent domain_shutdown() will generate a new VIRQ.
>>
>> Therefore, a new @releaseDomain will arrive at a later point.
> Well, jolly good.
>
>>> Should libxl simply treat domains in state SHUTDOWN/SUSPEND as if they
>>> were running, and not issue a notification to anyone ?
>> As far as libxl_evenable_domain_death() is concerned, yes.
> Would you like to prepare a patch ?

I don't have a repro of the issue.  This thread was merely me triaging
an issue reported by Wen, given some `git grep`.  (There are actually 3
different bugs on different subthreads of this thread.)

>
>> In general however, no.  Consider a libxl user (such as a snapshotting
>> utility) which asks a domain to suspend to quiesce the disks and then
>> intends to resume the domain.
> Currently such a utility would have to use
> libxl_evenable_domain_death to discover when the domain suspends, but
> that would cause breakage as discussed in this thread.  So I think
> such a utility would need a new libxl evenable interface.  Do you
> agree ?

This looks like a yakk.

Changing the behaviour of libxl_evenable_domain_death() will break the
API and also break in-guest users.  It also doesn't return the shutdown
code, so the caller can't loop while shutdown && suspend.

I can't think of a solution which doesn't involve making a brand new
function written from scratch.

~Andrew

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