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 02:43:13 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Steven.Hand@xxxxxxxxxxxx, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Mon, 05 Sep 2005 01:41:10 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: Message from Rusty Russell <rusty@xxxxxxxxxxxxxxx> of "Mon, 05 Sep 2005 11:05:37 +1000." <1125882337.10469.16.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 Mon, 2005-09-05 at 01:26 +0100, Steven Hand wrote:
>> Rusty wrote:
>> >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.
>
>A system with duplicate names is not really sane.  All user tools are
>going to use names, so differentiation by uuids doesn't help.  Whether
>name uniqueness is enforced or not I don't really mind: people are
>creative, they can generate unique names all kinds off ways (even uuids
>if that's what floats your boat).
>
>> 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.
>
>Sure, and the name fits these as well as UUID.  

Well UUIDs can be regular making code simpler; they can be transparently
to the tools treated as structured allowing independent allocation and 
verification; they provide a simple unambiguous ordering; they sidestep
issues of internationalization; and they firmly place xenstore out of 
the view of the end-user which I think is quite a good thing. 

>You cannot, in general, meet your requirements, UUID or no, because you 
>can fork and destroy the original, etc.

I don't understand this - can you explain? 

(or is this just some kind of general impossibility statement regarding 
asynchronous messages and byazantine failures??) 


>> I guess we could try to use
>> human readable stuff for this, but I think having the extra level of 
>> indirection makes it easier. 
>
>I disagree; more indirection, more concepts to master, more room for
>confusion, more code, worse store layout, with no more features.
>
>Seems all bad from where I'm sitting 8(

Well I certainly wouldn't want to confuse you by requiring you to master 
more concepts... :-) 

However: I think we both /agree/ on the fact that domain ids should be 
used to name things which are about domains (e.g. event channel ids 
and backend domain ids, etc, etc). 

And i think we both /agree/ that within a domain's piece of xenstore, 
that there's at least one 'name' which is a cluster-wide unique string
and which persists across save/restore/migrate. 

Yes? 


cheers,

S.


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