All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Pratt <Ian.Pratt@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Gianni Tedesco (3P)" <gianni.tedesco@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [PATCH]: xl: use libuuid to generate random UUID's
Date: Tue, 10 Aug 2010 12:43:59 -0700	[thread overview]
Message-ID: <4C61ABFF.4020309@goop.org> (raw)
In-Reply-To: <19553.28415.356871.984129@mariner.uk.xensource.com>

  On 08/10/2010 08:23 AM, Ian Jackson wrote:
> Gianni Tedesco (3P) writes ("RE: [Xen-devel] [PATCH]: xl: use libuuid to generate random UUID's"):
>> On Mon, 2010-08-09 at 11:51 +0100, Ian Jackson wrote:
>>> VM uuids are not stable in xend nor xl.  Perhaps xl should hash the VM
>>> name, which is stable and supposedly unique.
>> But they can be made to be stable and I suppose this is the point here.
> No, I don't think VM uuids can be made stable in xl.  If for no other
> reason than that localhost migration would be impossible.

Stable uuids are a primary requirement.  Localhost migration is a 
parlour trick which is useful for testing but little else.  Therefore, 
localhost migration should work around stable uuids rather than the 
other way around (failing if you've got a stable uuid defined would be a 
reasonable answer).

xl's current behaviour of ignoring the config file uuid is an 
unequivocal bug.

> I think the only way to have stable MAC addresses is to derive them
> from the VM name, or for the user to explicitly write a MAC address in
> the config file.

Deriving from the vm name makes sense as a fallback if they haven't 
specified a uuid.  But I think in that case it would make more sense to 
derive the uuid from the domain name, and then everything else from that 
uuid.

> Users who do the latter will find things continue to work no matter
> how we change the default scheme, and the default is already somewhat
> broken, so perhaps we should indeed consider changing it.

If the default uuid is random at the moment, then it should be pretty 
safe to change it to anything else.

     J

  parent reply	other threads:[~2010-08-10 19:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-04 17:49 [PATCH]: xl: use libuuid to generate random UUID's Gianni Tedesco
2010-08-05  2:19 ` Ian Pratt
2010-08-05  2:27   ` Jeremy Fitzhardinge
2010-08-10 10:44     ` Ian Campbell
2010-08-10 11:14       ` Vincent Hanquez
2010-08-10 14:38         ` Stefano Stabellini
2010-08-10 19:38       ` Jeremy Fitzhardinge
2010-08-05  9:19   ` Vincent Hanquez
2010-08-05 10:13     ` Christoph Egger
2010-08-05 11:11       ` Vincent Hanquez
2010-08-05 16:42         ` Stefano Stabellini
2010-08-05 10:34     ` Stefano Stabellini
2010-08-09 10:51   ` Ian Jackson
2010-08-09 11:04     ` Gianni Tedesco
2010-08-10 15:23       ` Ian Jackson
2010-08-10 15:24         ` Gianni Tedesco
2010-08-10 16:55           ` Ian Jackson
2010-08-10 16:06         ` Ian Pratt
2010-08-10 19:43         ` Jeremy Fitzhardinge [this message]
2010-08-11 11:15           ` Ian Jackson

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=4C61ABFF.4020309@goop.org \
    --to=jeremy@goop.org \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=Ian.Pratt@eu.citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=gianni.tedesco@citrix.com \
    --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.