From: Dan Smith <danms@us.ibm.com>
To: xen-devel@lists.xensource.com
Cc: Sean Dague <sean@dague.net>
Subject: Re: xend falls over *a lot* in past 2 weeks
Date: Tue, 13 Sep 2005 13:03:04 -0700 [thread overview]
Message-ID: <87hdco7n2f.fsf@us.ibm.com> (raw)
In-Reply-To: 20050913193543.GA7021@underhill.no-ip.org
SD> Any thoughts on why this is might be the case?
So, as far as I can tell, there is some state being kept in xend,
which causes the problem. In my testing, I create and destroy a
domain repeatedly with the same name. Sometimes a destroy operation
marks the domain in XenDomainDict as "terminated", but doesn't
actually remove it. Then, xend allows another domain by the same name
to be created, thus corrupting xend's internal domain list. Next, the
create routines in xend try to unpause the domain referenced by the
name, which turns up the record from the list of the old domain, and
therefore the old domid. The unpause routine makes a call to libxc to
unpause the old domid, which isn't found in the list, so ESRCH ("No
such process") is returned.
It seems to me that there are (at least) two problems here:
1. The domain objects in xend's list sometimes seem to stick around
longer than they should after a destroy operation.
2. Xend will create a duplicate domain if asked, and therefore will
corrupt its own internal list.
I'm testing a patch right now that will cause xend to do a quick
sanity check before creating a domain to make sure that the list does
not currently contain a domain object of the same name.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com
prev parent reply other threads:[~2005-09-13 20:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-13 19:35 xend falls over *a lot* in past 2 weeks Sean Dague
2005-09-13 20:03 ` Dan Smith [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87hdco7n2f.fsf@us.ibm.com \
--to=danms@us.ibm.com \
--cc=sean@dague.net \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.