[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [RFC] Switching store to use domain id's for keys



Christian Limpach wrote:

The reasoning seems obvious to me, there's no easy way to get the UUID for a domain so constructing a UUID based path outside of Xend is very difficult.

Hmm, it's less than 40 lines of C code to iterate over the /domain entries
and find a domain with a matching name or id.  It would be convenient
to have library functions which does this...
The linear search just makes me sad :-) There can still be a UUID key within the /domain tree. One can just as easily code up a function to resolve UUIDs to domain IDs by doing a linear search.

I think the key is to optimize for the common case here. Since, today and I reckon for the foreseeable future, the management functions take domain IDs, it seems like the right thing to optimize for.

We'd like the identifier for a domain to remain the same after
relocating the domain to a different physical machine.[1]
Yes, this is a tough thing to get right. It straight forward for migration, but what about save/restore, cloning, etc. It seems almost better to let UUIDs preservation to be a higher level management task.

If we consider changing this, I'd go for /domain/<nodeid>-<domid>.  It
would make it easy to find the path for a domain on its home node but
it wouldn't work anymore once you move the domain to a new host.
I'm partial to a more hierarchical model. Something like <nodeid>/domain/<domid>. It lets <nodeid> become part of an implicit path...

Regards,

Anthony Liguori

Or, if we really want to use UUIDs in the node path, perhaps we can add UUIDs to the domain structure in the hypervisor so that we can actually query it through getdomaininfo?

We've considered this but everytime we've found that the reason why
we wanted it was invalid.

In any case, it seems reasonable to move the console entries to the
domain tree then...

   christian

[1] this is currently broken since we create a new uuid on restore.
The issue is that device configuration is local to the host where the
domain is running and there's a short period of time where we want
device information for two hosts present at the same time.




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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.