Xen devel - Sep 2010 - xl: multiple domain with the same name allowed?

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?

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12


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

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)

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

Ian.


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

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


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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

Andre Przywara writes ("[Xen-devel] xl: multiple domain with the same name
allowed?"):
> I realized that the xl tool allows to create multiple domains with the 
> same name:
This is a bug.

Ian.

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

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.

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

Ian.



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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, 2010-09-13 at 11:17 +0100, Marc - A. Dahlhaus
wrote:
> xl would have to refuse to start any of the domains or am i missing
> anything here?
It only has to prevent the second domain using a particular device from
starting. The first domain to run is safe in its own right, even if it
wasn''t intended to give that device to the domain.
> 
> Where to draw the line for preventing user stupidity?!
> 
> It would be a can of worms that would get opened up here IMO.
I htink xend has done this for a long time, I don''t think it is a new
can of worms.

Ian.


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

Ian Campbell writes ("Re: [Xen-devel] xl: multiple domain with the same
name allowed?"):
> I htink xend has done this for a long time, I don''t think it is a
new
> can of worms.
Yes, xend has.  I''m not sure it even has a way of overriding it.

How should we detect this situation ?  Look for instances of blktap
and mounted filesystems and LVM having it open and ... ?  (I''m not
even sure how it''s possible to find out whether an LVM PV is
"open"
according to the LVM system.)

Ian.

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

On Tue, 2010-09-14 at 17:37 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] xl: multiple domain with the
same name allowed?"):
> > I htink xend has done this for a long time, I don''t think it
is a new
> > can of worms.
> 
> Yes, xend has.  I''m not sure it even has a way of overriding it.
> 
> How should we detect this situation ?  Look for instances of blktap
> and mounted filesystems and LVM having it open and ... ?  (I''m not
> even sure how it''s possible to find out whether an LVM PV is
"open"
> according to the LVM system.)
I don''t really know the details but tools/hotplug/Linux/block contains
functions such as check_{device,file}_sharing() which I always presumed
was how xend ended up doing the right thing for shared devices. If
sharing is happening it appears to write the hotplug-error and
hotplug-status nodes in xenstore.

Ian.


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