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] PATCH: Fix name uniqueness check

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] PATCH: Fix name uniqueness check
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Mon, 1 Oct 2007 23:12:16 +0100
Cc: Jim Fehlig <jfehlig@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
Delivery-date: Mon, 01 Oct 2007 15:13:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20071001181811.GH11414@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070927204023.GQ17433@xxxxxxxxxx> <C32645E1.E419%Keir.Fraser@xxxxxxxxxxxx> <20071001135718.GA11414@xxxxxxxxxx> <20071001181811.GH11414@xxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Mon, Oct 01, 2007 at 07:18:11PM +0100, Daniel P. Berrange wrote:
> There are 6 basic test cases:
> 
>    a. same name + same UUID:
>    b. diff name + same UUID:
>    c. same name + diff UUID:
>    d. diff name + diff UUID:
>    e. same name + no UUID:
>    f. diff name + no UUID:
> 
> These need to be tested with 'xm create' and 'xm new', and all tests need to
> be done with the pre-existing VM both inactive, and active.

So, to 6 tests under 4 scenarios, gives 24 combinations. NB in the list
above from my previous mail I flipped some letters compared to my actual
testsuite - so pay attention to the letters used below, not the ones above.

UUID is the primary unique key for VMs. Name is the secondary unique
key. The former takes priority, eg redefining with existing UUID, but
different name causes a rename in the config stored.

  - Scenario 1: xm new + existing inactive vm

      a. same name + same UUID:  ALLOW  (redefine)
      b. same name + diff UUID:  REJECT (clashing name)
      c. diff name + same UUID:  ALLOW  (redefine+rename)
      d. diff name + diff UUID:  ALLOW  (define)
      e. same name + no UUID:    REJECT (clashing name)
      f. diff name + no UUID:    ALLOW  (define)

  - Scenario 2: xm create + existing inactive vm

      a. same name + same UUID:  ALLOW  (create)
      b. same name + diff UUID:  REJECT (clashing name)
      c. diff name + same UUID:  ALLOW  (create)
      d. diff name + diff UUID:  ALLOW  (create)
      e. same name + no UUID:    REJECT (clashing name)
      f. diff name + no UUID:    ALLOW  (create)

  - Scenario 3: xm new + existing active vm

      a. same name + same UUID:  ALLOW  (redefine)
      b. same name + diff UUID:  REJECT (clashing name)
      c. diff name + same UUID:  ALLOW  (redefine+rename)
      d. diff name + diff UUID:  ALLOW  (define)
      e. same name + no UUID:    REJECT (clashing name)
      f. diff name + no UUID:    ALLOW  (define)

  - Scenario 4: xm create + existing active vm

      a. same name + same UUID:  REJECT (clashing name/uuid)
      b. same name + diff UUID:  REJECT (clashing name)
      c. diff name + same UUID:  REJECT (clashing uuid)
      d. diff name + diff UUID:  REJECT (disk image in use)
      e. same name + no UUID:    REJECT (clashing name)
      f. diff name + no UUID:    REJECT (disk image in use)

Basically the allow/reject rules at the same for the first 3 scenarios.
The reject scnarios are dealt with by the _checkName() function in the
XendDomainInfo class. Only in the last one do we have to reject all combos
more aggressively. This is because if you 'xm create' the same VM with 
identical details it wouldn't be stopped by the hotplug disk checks in 
all cases. This is not possible to validate from _checkName() since it 
does not have enough context to know that the new VM is about to be started.
So we have to make extra checks in the 'create()' function in XendDomainInfo

I am attaching a file 'test.sh' which creates a test VM & configs and runs
through all these 24 scenarios. Feel free to add this to XenD's regression
test suite if practical.

So the actual patches needed...

In 3.1-testing

 - Revert 15168:a717cb2fac90  (aka pull in 15973:8817a53c030f from 
   xen-unstable.hg). This addresses scenarios 1-3 above

 - Apply the 'xen-create-name-uniqueness.patch'  which adds a check
   to XendDomainInfo.create() to deal with special needs of scenario 4

In xen-unstable

 - Revert 15642:207582c8d88b (this patch is now bogus since 15168:a717cb2fac90
   is already reverted by 15973:8817a53c030f). It only covered 'xm new'
   where as proposed patches cover 'xm new' and 'xm create' together

 - Apply the 'xen-create-name-uniqueness.patch'  which adds a check
   to XendDomainInfo.create() to deal with special needs of scenario 4

I don't have a xen-unstable.hg box currently, so my testing of these patches
has been against the 3.1-testing.hg tree. The 'test.sh' script should be able
to validate them for unstable. BTW, run test.sh with /etc/xen as CWD.

  Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

Regards,
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  -=| 

Attachment: xen-create-name-uniqueness.patch
Description: Text document

Attachment: test.sh
Description: Bourne shell script

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