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-tools] Re: [Xen-devel] [PATCH] Make xend reject duplicates and

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-tools] Re: [Xen-devel] [PATCH] Make xend reject duplicates and rename zombies
From: Christian Limpach <christian.limpach@xxxxxxxxx>
Date: Fri, 16 Sep 2005 20:52:05 +0100
Cc: Xen Tools Developers <xen-tools@xxxxxxxxxxxxxxxxxxx>, Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 16 Sep 2005 19:49:45 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pp+CRFAyqPf6aqFRGTWFUzexirmUL4cFy+WjIm2uQfQSU28ICOBdmkpIpCZ6VP2LyxzU1mGMli/iNNWaixZR3gXn7TLetsqrqhLoE+pUwH6LqwTkHOFcvvzaJgKRK0Du3eysQG4f6auC9IIQy2Jyk4TUF3t6x3lkaf8tAXhpot8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4329C366.2070006@xxxxxxxxxx>
List-help: <mailto:xen-tools-request@lists.xensource.com?subject=help>
List-id: Xen control tools developers <xen-tools.lists.xensource.com>
List-post: <mailto:xen-tools@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=unsubscribe>
References: <87br2uz5yj.fsf@xxxxxxxxxx> <4329C366.2070006@xxxxxxxxxx>
Reply-to: Christian.Limpach@xxxxxxxxxxxx
Sender: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx
On 9/15/05, Anthony Liguori <aliguori@xxxxxxxxxx> wrote:
> I think this is not the right solution to the problem at hand.  The
> problem stems from the fact that xm destroy is just a call to
> xc_domain_destroy which is really just a request to the hypervisor to
> destroy the domain.

Indeed.

> Therefore, there is a race condition if you assume that the domain is
> dead after xm destroy returns.  This patch renames the domain name which
> prevents a name class but does not solve the general problem.  Consider,
> for instance, if a domain is using a block device and you do an xm
> destroy.  It is not safe to create a new domain with that same block
> device until you know that the previously mentioned domain is gone.

I think renaming would make sense if a domain is crashed.  You might
want to keep the domain around to attach a debugger to it but at the
same time restart a fresh copy as soon as possible.

> This patch would allow:
> xm destroy xmexample1 && xm create /etc/xen/xmexample1
> 
> I think the right solution is to make xm destroy not return until the
> domain has actually gone away and add a flag to xm destroy to return
> immediately if that behavior is ever desired.

Sounds good.

> I'll work up a patch tonight after class.

Thanks!

     christian

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