From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Xen-tools] Re: [PATCH] Make xend reject duplicates and rename zombies Date: Fri, 16 Sep 2005 16:37:23 -0500 Message-ID: <432B3B13.4070705@us.ibm.com> References: <87br2uz5yj.fsf@us.ibm.com> <4329C366.2070006@us.ibm.com> <3d8eece205091612523cf7b900@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3d8eece205091612523cf7b900@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christian.Limpach@cl.cam.ac.uk Cc: Xen Tools Developers , Dan Smith , Xen Developers List-Id: xen-devel@lists.xenproject.org Christian Limpach wrote: >On 9/15/05, Anthony Liguori 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. > > As long as you can make sure to rename *after* all of the devices have been properly torn down. Otherwise, we need to make sure to make it well known that restarting a domain after a crash can result in very bad things :-) Regards, Anthony Liguori >>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 > > >