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] Re: [RFC] Switching store to use domain id's for keys

To: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [RFC] Switching store to use domain id's for keys
From: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Date: Mon, 05 Sep 2005 01:26:55 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Steven.Hand@xxxxxxxxxxxx, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Mon, 05 Sep 2005 00:24:54 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: Message from Rusty Russell <rusty@xxxxxxxxxxxxxxx> of "Mon, 05 Sep 2005 10:11:20 +1000." <1125879080.24158.27.camel@xxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>On Wed, 2005-08-31 at 10:28 +0100, Christian Limpach wrote:
>> On Tue, Aug 30, 2005 at 03:32:46PM -0500, Anthony Liguori wrote:
>> > Perhaps now is a good time to reconsider just using domain ids instead 
>> > of UUIDs for the paths?  In a cluster we could just use 
>> > <nodeid>/domain/<domid> for unique identification.
>> 
>> We'd like the identifier for a domain to remain the same after
>> relocating the domain to a different physical machine.[1]
>
>You're never going to have the property that a uuid always maps to the
>same domain, or a domain always has the same uuid, if we ever introduce
>forking of domains by any method.  So, I think this is a losing battle,
>but it's causing a mess of the store as a side effect.
>
>As far as I can tell, UUIDs are a third identifier of domains, which buy
>nothing over the existing two: names (cluster-wide unique, human
>readable, slow), and domids (locally unique, fast).

Well one issue is that cluster-wide unique human readable names are 
tricky to enforce. Right now what we need is something which refers
to the same "virtual machine" regardless of which domain it currently
inhabits. I.e. across save/restore, across migrate, etc. If this is 
unique to a "virtual machine", then a 'fork' (when we get it) is going 
to cause a new one of these to be created. I guess we could try to use
human readable stuff for this, but I think having the extra level of 
indirection makes it easier. 

Of course this means that per-domain (rather than per virtual machine) 
state such as event channels and mfns of shared memory should be indexed
by domain id in the store, not by uuid. The uuid is an important part 
of a domain's identity but it's effectively a 'foreign key' rather than
the primary key of the domain information. 


cheers,

S.

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