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
|