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

["Andrew D. Ball" <aball@xxxxxxxxxx>]

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