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-users

[Xen-users] domU lifecycles, xenstore, and UUIDs [not necessarily 128-bi

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] domU lifecycles, xenstore, and UUIDs [not necessarily 128-bit ones]
From: "Andrew D. Ball" <aball@xxxxxxxxxx>
Date: Thu, 29 Dec 2005 19:17:28 -0500
Delivery-date: Fri, 30 Dec 2005 00:22:11 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Reply-to: aball@xxxxxxxxxx
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
At least from the 'xm' commands' interface, it looks like domU's just
disappear after an 'xm destroy', which I've been using to cut turn off
the virtual power switches of domU's.  Is this by design?

I'm trying to think of a good way to identify a domU throughout its
lifecycle, which for me goes all the way from initial configuration to
an explicit choice of the user to get rid of it, regardless of how many
domU uptimes or configuration changes have occurred.  

So far, the best thing that I can think of is to use the regular, human-
readable domU names to uniquely identify a domU across its lifecycle.
If a user chooses to change this name, I suppose it's not unreasonable
for the domU's unique identification to change.

I run up against a snag for fully virtualized domU's though.  It seems
appropriate to have a regular, virtual firmware based, 128-bit UUID for
fully virtualized domU's.  Any suggestions on what to use for this or
reasons why it shouldn't be implemented?

(1) I could use the xenstore UUID, if it can persist across a domU
lifecycle.

(2) I could do something odd like using a cryptographic hash on the
human-readable name of the fully virtualized domU that outputs 128 bits.
I don't want to limit the size of the domU symbolic names.  I could at
least guarantee no collisions for names with fewer than some number of
characters (say 64), but a suitable hash could be useful for names of
arbitrary length.

(3) I could try to generate a UUID for fully virtualized domU's at
configuration time, saving this somewhere in the domU's configuration.
I'd like a generic metadata section of domU configurations for things
like this, so that I can add arbitary name/value pairs.  Objections to
this approach?

Thanks for your help.
Andrew

-- 
Andrew D. Ball
aball@xxxxxxxxxx

"Festina Lente" $\approx$ "Make hast slowly"
  -- Caesar Augustus


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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-users] domU lifecycles, xenstore, and UUIDs [not necessarily 128-bit ones], Andrew D. Ball <=