From: "Marc - A. Dahlhaus" <mad@wol.de>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: xl: multiple domain with the same name allowed?
Date: Fri, 10 Sep 2010 12:34:46 +0200 [thread overview]
Message-ID: <1284114886.25428.55.camel@marc> (raw)
In-Reply-To: <1284108345.14311.5513.camel@zakaz.uk.xensource.com>
Am Freitag, den 10.09.2010, 09:45 +0100 schrieb Ian Campbell:
> On Fri, 2010-09-10 at 09:03 +0100, Andre Przywara wrote:
> > Hi,
> >
> > I realized that the xl tool allows to create multiple domains with the
> > same name:
> > # xl create ttylinux.xl
> > # xl create ttylinux.xl
> > # xl list
> > Name ID Mem VCPUs State Time(s)
> > Domain-0 0 5498 4 r----- 1647.8
> > TTYLinux-NUMA 22 2043 4 -b---- 29.9
> > TTYLinux-NUMA 23 2043 4 r----- 21.3
> > xm only shows one domain, it also refuses to start another instance (in
> > opposite to xl)
> > # xm list
> > Name ID Mem VCPUs State Time(s)
> > Domain-0 0 5498 4 r----- 1665.0
> > TTYLinux-NUMA 22 2043 4 -b---- 133.1
> > # xm create ttylinux.xl
> > Using config file "./ttylinux.xm".
> > Error: Domain 'TTYLinux-NUMA' already exists with ID '22'
> >
> > Is the xl behavior intended or just a bug?
>
> It's a bug (or at best a missing feature).
>
> While creating multiple domains with the same name is only confusing to
> the user (and therefore it would be better, I think, for xl to enforce
> uniqueness by default if possible) a more serious issue is allowing
> multiple domains to be started which refer to the same storage since
> this can lead to data corruption. (the obvious way to do this
> accidentally is starting same domain twice, or via a typo in your
> configuration file)
Wouldn't this prevent the "shared block device with a cluster aware
filesystem on it" use-case?
> There was some discussion of this on xen-devel several weeks back but I
> don't think anyone quite got to the bottom of why the locking in the
> block backend hotplug scripts wasn't preventing the second and
> subsequent domains using a given storage backend from connecting to
> their devices, which would prevent damage from occurring. Really xl
> ought to be capable of detecting this situation before even starting a
> domain, which is what I think xend does. (perhaps this is harder with xl
> due to the lack of an overarching daemon for coordination).
IMO starting the same configuration file twice at the same time should
be forbidden. Also the domUs name should be unique because you can't
distinguish them in listings otherwise.
For anything else: Thrust the user.
If he fails, he will learn why and will not do the same mistake again.
If we need to guide the user a bit more on this topics, than
documentation would be the right place to do it IMO.
Error messages from the tools in cases where they restrict possible
valid use-cases are a bit scary...
Marc
next prev parent reply other threads:[~2010-09-10 10:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-10 8:03 xl: multiple domain with the same name allowed? Andre Przywara
2010-09-10 8:45 ` Ian Campbell
2010-09-10 10:34 ` Marc - A. Dahlhaus [this message]
2010-09-10 14:27 ` Gianni Tedesco
2010-09-13 8:42 ` Ian Campbell
2010-09-13 10:17 ` Marc - A. Dahlhaus
2010-09-13 13:40 ` Ian Campbell
2010-09-14 16:37 ` Ian Jackson
2010-09-15 8:37 ` Ian Campbell
2010-09-10 17:51 ` Ian Jackson
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=1284114886.25428.55.camel@marc \
--to=mad@wol.de \
--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.