From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Stekloff Subject: Re: [PATCH] xenctld - a control channel multiplexing daemon Date: Wed, 26 Jan 2005 19:48:24 -0800 Message-ID: <1106797593.3228.4.camel@localhost.localdomain> References: <1106322956.17263.26.camel@localhost> <1106698862.19729.40.camel@dyn318051bld.beaverton.ibm.com> <1106767902.25573.7.camel@localhost> <1106769687.25575.21.camel@localhost> <1106776160.19729.66.camel@dyn318051bld.beaverton.ibm.com> <1106780255.7268.9.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1106780255.7268.9.camel@localhost> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Anthony Liguori Cc: Michael Hohnbaum , andrew.warfield@cl.cam.ac.uk, xen-devel@lists.sourceforge.net, Keir Fraser List-Id: xen-devel@lists.xenproject.org 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? I think checkpoints should be stored by the domain id/key for the domain they are from, using date as an identifier. If you're going to run that checkpoint image, it then gets a new id to run under and a new entry as a domain. Sorry about blasting out messages, just thinking about the questions everyone has raised. Thanks, Dan > There's a lot to be thought about. I think punting the problem (as Andy > suggests) is the right approach for now. > > Regards, ------------------------------------------------------- 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