On Wed, 2005-01-26 at 14:57, 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.
>
> 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?
>
> There's a lot to be thought about. I think punting the problem (as Andy
> suggests) is the right approach for now.
I believe we should create a single store and API. We can start with the
current domain configuration files. We create a single store and a set
of functions to access it. Then atop that, we can create multiple single
function management apps if you want. You could have an app that just
manages the active domains. You could have an app that does suspend,
etc. Yet you have one store with a common set of commands to access the
information.
Having this architecture, starting it small even, will help with
answering the harder questions down the road.
Thanks,
Dan
-------------------------------------------------------
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
|
Home