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/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Make xend reject duplicates and rename zombies

To: Dan Smith <danms@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Make xend reject duplicates and rename zombies
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Thu, 15 Sep 2005 13:54:30 -0500
Cc: Xen Tools Developers <xen-tools@xxxxxxxxxxxxxxxxxxx>, Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 15 Sep 2005 18:53:40 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <87br2uz5yj.fsf@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <87br2uz5yj.fsf@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050912)
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.

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.

This patch would allow:

xm destroy xmexample1 && xm create /etc/xen/xmexample1

Even though it might really be conflicting. This could lead to *very* subtle device corruption down the road.

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.

I'll work up a patch tonight after class.


Anthony Liguori

Dan Smith wrote:

This patch is an update of my previous anti-duplicate-domain patch.
Now, we check an existing same-name domain to see if it's in the
"terminated" state, renaming it to "zombie-domid-name" if so.

This basically makes the problem go away for me, as it gives the dying
domain time to clean itself up.

Test 10_create_fastdestroy from the next release of xm-test validates
that this fixes the problem.

Signed-off-by: Dan Smith <danms@xxxxxxxxxx>


diff -r c27431cf81f9 tools/python/xen/xend/XendDomain.py
--- a/tools/python/xen/xend/XendDomain.py       Thu Sep 15 13:17:24 2005
+++ b/tools/python/xen/xend/XendDomain.py       Thu Sep 15 08:44:22 2005
@@ -297,6 +297,20 @@
        @param config: configuration
        @return: domain
+        existing = self.domains.get_by_name(sxp.child_value(config, "name"))
+        if existing:
+            if existing.is_terminated():
+                newname = "zombie-%i-%s" % (existing.domid, existing.name)
+                log.debug("Renaming zombie domain %s -> %s" %
+                          (existing.name, newname))
+                existing.setName(newname)
+            else:
+                log.debug("Attempt to create duplicate domain %s" %
+                          existing.name)
+                raise XendError("Domain %s already exists as %i!" %
+                                (existing.name, existing.id))
+ dominfo = XendDomainInfo.create(self.dbmap, config)
        return dominfo



Xen-devel mailing list

Xen-devel mailing list