From: Rusty Russell <rusty@rustcorp.com.au>
To: Steven Hand <Steven.Hand@cl.cam.ac.uk>
Cc: xen-devel <xen-devel@lists.xensource.com>,
Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
Subject: Re: Re: [RFC] Switching store to use domain id's for keys
Date: Mon, 05 Sep 2005 11:05:37 +1000 [thread overview]
Message-ID: <1125882337.10469.16.camel@localhost.localdomain> (raw)
In-Reply-To: <E1EC4p5-0001Zh-00@mta1.cl.cam.ac.uk>
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. You cannot, in general,
meet your requirements, UUID or no, because you can fork and destroy the
original, etc.
> 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(
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
next prev parent reply other threads:[~2005-09-05 1:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-30 20:32 [RFC] Switching store to use domain id's for keys Anthony Liguori
2005-08-31 9:28 ` Christian Limpach
2005-08-31 20:40 ` Anthony Liguori
2005-09-05 0:11 ` Rusty Russell
2005-09-05 0:26 ` Steven Hand
2005-09-05 1:05 ` Rusty Russell [this message]
2005-09-05 1:43 ` Steven Hand
2005-09-05 2:53 ` Rusty Russell
2005-09-05 8:35 ` Steven Hand
2005-09-05 8:52 ` Keir Fraser
2005-09-06 0:07 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1125882337.10469.16.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=Christian.Limpach@cl.cam.ac.uk \
--cc=Steven.Hand@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.