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: andrew.warfield@xxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon
From: Michael Hohnbaum <hohnbaum@xxxxxxxxxx>
Date: Tue, 25 Jan 2005 16:21:01 -0800
Cc: Anthony Liguori <aliguori@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 26 Jan 2005 00:21:12 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <eacc82a4050121083937725a83@xxxxxxxxxxxxxx>
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>
Organization: IBM LTC
References: <1106322956.17263.26.camel@localhost> <eacc82a4050121083937725a83@xxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
On Fri, 2005-01-21 at 16:39 +0000, Andrew Warfield wrote:

Thanks for the info.  


> > 4) Factor out most of xen interaction in xcs to standard libraries.
> 
> Much of the xen interaction in xcs _is_ already in shared libraries
> (libxc and libxutil).  The control channels can only be safely bound
> by a single consumer in dom0 -- xcs just serves to multiplex this
> access.  The interfaces in xcs could probably do with some cleaning
> up, as they are reflective of my pulling a lot of the structure out of
> the python code in December.  I'm not sure what bits of it you'd like
> to see generalized out of xcs though...  can you be more specific?
>  
> > I see a three level architecture, the first level being highly portable
> > libraries that simplify interacting with Xen.  This would target every
> > platform Xen runs on.
> >  ...
> 
> This is what we have been shooting for with the new control tools: 1.
> libxc/xutil, 2. xcs, 3. higher-level tools.

Is it reasonable to expect that a port to another machine architecture,
assuming the libxc/xutil are provided, then xcs and higher-level tools
should just follow?

> 
> > Thoughts?  I'm willing to code these things up.  Just want to make sure
> > it's agreeable first.
> 
> Our current plan with the control tools is in fixing up a couple of
> things (1) how vm state is represented in dom0, and (2) how easy it is
> to add and maintain new tools, drivers, etc.
> 
> xcs is a first step, in that it allows new tools be run along side xend.
> 
> The next step, coming soon, will be a 'persistent store' which will be
> a repository for vm state.  This will hold things like active domain
> configurations, device details, etc.

What form do you see this persistent store taking?  Is it just for 
currently present VM's, or can it be used also to pre-configure
VM's and/or have pre-defined VM's?  I assume some sort of filesystem
backed entity is to be used for the persistent store, correct?
Format, content, etc.?
> 
> In addition to this, we have been discussing the option of adding
> endpoint addressing to the control messages.  So driver setup, for
> instance, would move toward a control tool pushing details into the
> store prior to starting the domain.  the frontend driver would then
> query the store for the backend details, and then address the backend
> directly.  This should make extending the tools considerably easier.
> 
> This is all very high on the to do list, and should start to emerge
> over the next while.  It would be great to discuss design points in
> more detail on the list.

Yes.  This is a good overview.  More details especially in regards to
the persistent store, and the set of tools being built would add to
this discussion.  Also, it is likely that I (and others) can provide
development and testing assistance if we understand what is being
developed and where our contributions can be used.

Thanks.

              Michael
> 
> Things are a little busy here right now, so i hope this isn't too brief. ;)
> 
> best,
> a.

-- 
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

<Prev in Thread] Current Thread [Next in Thread>