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

[Michael Hohnbaum <hohnbaum@xxxxxxxxxx>]

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