On Tuesday, November 15, 2005 3:26 PM, Ewan Mellor
<mailto:ewan@xxxxxxxxxxxxx> wrote:
> On Tue, Nov 15, 2005 at 11:43:49AM -0800, Cihula, Joseph wrote:
>
>> I noticed that the changesets around 7378:bd3268de4145 introduced the
>> xen_domain_handle_t param to xc_create_domain(), the struct domain,
>> etc. and call it a "tool UUID".
>>
>> Can someone explain how this is envisioned being used (xend sets it
>> to some magic values but I don't see it get used anywhere)?
>
> Theoretically, this value is just an opaque block of bits, usable by
> anyone
> for any purpose. Xen just stores it along with the domain, and gives
> it back
> again when you ask.
>
> Xend uses it as a unique identifier for a VM. In this terminology, a
> "VM" is a running guest. The VM may migrate to a different machine
> (where it would
> become a different domain) or it may be rebooted, in which case it
> would become
> a different domain on the same machine. However, the VM remains the
> same, and
> is identified by its unique ID (the UUID).
>
> It is useful for Xend to be able to store this UUID along with the
> domain as
> it makes it easy for Xend to restart (say after a crash) and yet be
> able to
> reconcile the contents of the store with the current running domains.
>
> This is just what Xend uses it for. In a world without Xend, you
> might use the
> UUID for something else. Of course, at the moment, no-one has a
> system
> that has Xen but is without Xend. However, this explains the
> slightly curious
> wording of the xen_domain_handle_t.
>
> Ewan.
Then I suppose that the fact that the xend code always seems to use the
same values (the good old 'deadbeef') is just temporary.
Going forward, if we want tools to interoperate then I think that it
makes more sense to specifically define these fields rather than
consider them black boxes or tool-specific. Even though in the
short-term only one (perhaps mutually exclusive) tool may need to use
this value it's semantics may end up being depended upon in several
components (libraries, other tools, etc.) that would be used by an
alternate (to the creation) tool.
Joe
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home