xen-devel
RE: [Xen-devel] Should "xm restore" be able to create two domains with t
> -----Original Message-----
> From: Petersson, Mats
> Sent: 22 May 2007 13:03
> To: Petersson, Mats; Daniel P. Berrange; Keir Fraser
> Cc: xen-devel
> Subject: RE: [Xen-devel] Should "xm restore" be able to
> create two domains with the same name?
>
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> > Petersson, Mats
> > Sent: 22 May 2007 12:16
> > To: Daniel P. Berrange; Keir Fraser
> > Cc: xen-devel
> > Subject: RE: [Xen-devel] Should "xm restore" be able to
> > create two domains with the same name?
> >
> >
> >
> > > -----Original Message-----
> > > From: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx]
> > > Sent: 18 May 2007 15:08
> > > To: Keir Fraser
> > > Cc: Petersson, Mats; xen-devel
> > > Subject: Re: [Xen-devel] Should "xm restore" be able to
> > > create two domains with the same name?
> > >
> > > On Fri, May 18, 2007 at 02:55:22PM +0100, Keir Fraser wrote:
> > > >
> > > >
> > > >
> > > > On 18/5/07 14:49, "Petersson, Mats"
> > <Mats.Petersson@xxxxxxx> wrote:
> > > >
> > > > > If I do "xm save dom file", followed by "xm restore file;
> > > xm restore
> > > > > file", I get two domains with the same name. Surely,
> > > that's not quite
> > > > > right? [Particularly since they both will be using the
> > > same disk-image,
> > > > > etc].
> > > >
> > > > You shouldn't do that. ;-)
> > > >
> > > > The second restore ought to fail when xend (or the hotplug
> > > scripts) realise
> > > > that the block device is already in use.
> > >
> > > The second restore ought to fail before it gets anywhere
> > near hotplug
> > > scripts. XenD should be enforcing name & UUID uniqueness
> > when creating
> > > guest VMs. Even 'xm create' lets you start the same guest twice
> > >
> > > http://lists.xensource.com/archives/html/xen-devel/2007-04/msg
> > > 00279.html
> >
> > Do you have any info to bracket back when this was still working? I
> > don't even really know (for sure) which file(s) to look at
> [of course,
> > it's limited to a few files, but all have quote a few
> changes lately],
> > since I don't know where this functionality used to be (or
> where it's
> > supposed to go). I'll keep looking, but having a "time-limit" for it
> > working correctly would reduce the number of changesets. The data of
> > your test is roughly 14800, so it has to be broken before that
> > changeset.
>
> Interestingly, I found that "xm-test" has a test
> ".../tests/create/04_create_conflictname_neg.py", which
> supposedly test this behaviour. It seems unchanged for quite
> some time - so presumably this test is now "failing".
I think I've found the place in XendDomainInfo.py and the fix... Testing
it right now.
--
Mats
>
> --
> Mats
> >
> > --
> > Mats
> > >
> > > Dan.
> > > --
> > > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1
> > > 978 392 2496 -=|
> > > |=- Perl modules: http://search.cpan.org/~danberr/
> > > -=|
> > > |=- Projects: http://freshmeat.net/~danielpb/
> > > -=|
> > > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF
> > > F742 7D3B 9505 -=|
> > >
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >
> >
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|