From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH]: xl: use libuuid to generate random UUID's Date: Tue, 10 Aug 2010 12:43:59 -0700 Message-ID: <4C61ABFF.4020309@goop.org> References: <1280944162.18490.219.camel@qabil.uk.xensource.com> <4FA716B1526C7C4DB0375C6DADBC4EA37AD0596B2F@LONPMAILBOX01.citrite.net> <19551.56759.804055.642585@mariner.uk.xensource.com> <1281351866.18490.252.camel@qabil.uk.xensource.com> <19553.28415.356871.984129@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <19553.28415.356871.984129@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: Ian Pratt , Xen Devel , "Gianni Tedesco (3P)" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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