Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon

[Michael Hohnbaum <hohnbaum@xxxxxxxxxx>]

On Wed, 2005-01-26 at 16:57 -0600, Anthony Liguori wrote:
> On Wed, 2005-01-26 at 15:49, Michael Hohnbaum wrote:
> 
> > While beyond the current focus, persistent store could feasibly
> > be used to hold domain definitions for non-existent domains and 
> > suspended domains.  One could envision adding a state field into
> > the domain configuration/definition.  Valid states for current 
> > capabilities would be {active, suspended, migrated, inactive}.  On
> 
> Yes, but the problem that occurs is uniquely identifying a domain.  In
> other words, what's the key used within the persistent store?
> 
> If it's domain id (which is what I assume it's going to be), you cannot
> tag it as having an "inactive" state because there's nothing that
> prevents a domain from being created with the same domain id.

Active domains would have a domain ID; inactive domains could be
labeled.
> 
> Also, if you try to assign domains UUIDs or something, what do you do
> for cloning/checkpointing?  Do you assign a new UUID on a clone but not
> on a checkpoint?  Does assigning new UUIDs propagate to things like MAC
> addresses or other things that are supposed to be unique?

Now you are making my head hurt.
> 
> There's a lot to be thought about.  I think punting the problem (as Andy
> suggests) is the right approach for now.

Punting is reasonable.  The immediate need is persistent store for 
active domains.  Other needs can be pushed up the management tool 
stack to reside with the consumer of the information.  Thus, the 
specific tool used to start a domain can define its own configuration
file (but please not a python script).  Whatever suspends/restarts
a domain can provide its own file for tracking suspended domains, etc.

Different usage scenarios could result in different tools providing
similar functions each which could choose to use a common config file
or define their own, based on needs.

While it is attractive to not have multiple similar config files,
trying to define a common one to contain all anticipated needed
information could easily become unwieldly.

                Michael

> 
> Regards,
> 
-- 
Michael Hohnbaum                             503 578 5486
hohnbaum@xxxxxxxxxx                          t/l 775 5486



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel