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-devel] xl: multiple domain with the same name allowed?

Am Montag, den 13.09.2010, 09:42 +0100 schrieb Ian Campbell:
> On Fri, 2010-09-10 at 11:34 +0100, Marc - A. Dahlhaus wrote:
> > 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?
> 
> Yes, it would.
> 
> I think it would be better to try and prevent disaster in the common
> case (which is not shared writeable block devices) and allow a
> configuration override for users who have uncommon needs like this.

The problem is that xl doesn't know what domU the "right domain" for the
mistakenly shared device is.

Because xl doesn't know anything about that storage device corresponds
to which domU for real in all situations of mistakenly configured
block-devices it would be unsafe to start any of the domU trying to
access the mistakenly shared block-device-path.

xl would have to refuse to start any of the domains or am i missing
anything here?

Where to draw the line for preventing user stupidity?!

It would be a can of worms that would get opened up here IMO.

> [...]
> > If he fails, he will learn why and will not do the same mistake again.
> 
> That's cold comfort when you've just trashed a filesystem because of a
> typo in a configuration file.

Well, "comfort" is the backup that one should have at hand in such
situations. ;)


Marc


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