Re: Domains not being destroyed properly

[Anthony Wright <anthony@overnetdata.com>]

On 24/06/2011 14:45, Ian Campbell wrote:
> On Fri, 2011-06-24 at 13:54 +0100, Anthony Wright wrote:
>> A reaper would have to maintain a list of domains as they were before the
>> notification to compare against the list after the notification to be
>> able to issue a notification for the domain that has died. If that list
>> got out of sync it would start issuing incorrect domain death notifications.
> You don't need to maintain a list, simply call libxl_list_domain() and
> for each returned domain examine the flags and shutdown reason to
> determine if it is dead (and why), dying or still running.
>
> Since you are explicitly arranging that nothing else will destroy
> domains once they die so they will always be in that list when you get
> to them.
My original thought on reaper was that it was only responsible for
helping notify user space applications of a domain's death,  but you
seem to be suggesting that it should also be responsible for tidying up
after a domain death as well. Isn't some other part of the system
already fulfilling this role?

It seems that for 'xl create' this tidy up is already being done, and I
had presumed the code for 'xl create -e' tidy up already exists but
wasn't working correctly. If you're saying the 'xl create -e' tidy up
code needs to be written, that's probably beyond my knowledge of xen,
and in any case I'm not sure it should be in reaper. Reaper should
notify user space of any domain destruction whether created by 'xl
create -e' or 'xl create'. If reaper did the tidy up for 'xl create -e'
it would have access to information needed to pass to the user space
applications, however for an 'xl create' domain death this information
may no longer be available since 'xl create' may have already tidied up.

>> Looking at the watch code while the code in xenstored_domain has the
>> domain id & name available, there doesn't seem to be the ability to be
>> able to add arguments to @releaseDomain to let it tell the watchers
>> which domain has been released to avoid having to maintain this list.
> It shouldn't matter due to the above but it is possible to add extra
> data to the vector included in the watch other than XS_WATCH_PATH and
> XS_WATCH_TOKEN). IOW you can add more stuff to the "data" vector in
> add_event. Linux's drivers/xen/xenfs/xenbus.c:watch_fired() even
> supports exporting the extra to userspace.