Andrew D. Ball
2005-Dec-30 00:17 UTC
[Xen-users] domU lifecycles, xenstore, and UUIDs [not necessarily 128-bit ones]
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@us.ibm.com "Festina Lente" $\approx$ "Make hast slowly" -- Caesar Augustus _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users