Re: [Xen-devel] xl: multiple domain with the same name allowed?

[Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>]

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).

Not sure sure unique names is a good idea because I see them as totally
cosmetic. What if I want a bunch of domains which I often want to run
the same command against all of them with a script - What other feature
can I use to mark them as belonging to such a group?

> > 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?

Also, it should only enforce one read/write use the storage, read-only
should be fine.

> > 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.

You can use -v and check the UUID, but then again domains with same UUID
also seem to work...

> 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...

yes, xl has plenty of scary error messages :)


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