WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Domains not being destroyed properly

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Domains not being destroyed properly
From: Anthony Wright <anthony@xxxxxxxxxxxxxxx>
Date: Fri, 24 Jun 2011 15:15:47 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Fri, 24 Jun 2011 07:16:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1308923134.32717.105.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4DFB3A90.70707@xxxxxxxxxxxxxxx> <1308657108.6920.25.camel@xxxxxxxxxxxxxxxxxxxxxx> <4E009530.2040108@xxxxxxxxxxxxxxx> <20110621133908.GE5650@xxxxxxxxxxxx> <4E00B019.5090108@xxxxxxxxxxxxxxx> <1308671090.6920.89.camel@xxxxxxxxxxxxxxxxxxxxxx> <4E00C0FC.1060305@xxxxxxxxxxxxxxx> <1308729414.6920.126.camel@xxxxxxxxxxxxxxxxxxxxxx> <4E048921.8000201@xxxxxxxxxxxxxxx> <1308923134.32717.105.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
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.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel