WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon
From: Daniel Stekloff <dsteklof@xxxxxxxxxx>
Date: Wed, 26 Jan 2005 19:48:24 -0800
Cc: Michael Hohnbaum <hohnbaum@xxxxxxxxxx>, andrew.warfield@xxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxx>
Delivery-date: Thu, 27 Jan 2005 03:50:12 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <1106780255.7268.9.camel@localhost>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <1106322956.17263.26.camel@localhost> <eacc82a4050121083937725a83@xxxxxxxxxxxxxx> <1106698862.19729.40.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <eacc82a405012606336357ab08@xxxxxxxxxxxxxx> <1106767902.25573.7.camel@localhost> <eacc82a40501261111572c3b11@xxxxxxxxxxxxxx> <1106769687.25575.21.camel@localhost> <1106776160.19729.66.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1106780255.7268.9.camel@localhost>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel