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

[Daniel Stekloff <dsteklof@xxxxxxxxxx>]

On Wed, 2005-01-26 at 06:33, Andrew Warfield wrote:
> Hi Michael,
> 
> > 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?
> 
> This seems pretty reasonable to me.  Most of what happens in xend
> right now is managing the state of the vms, much of the real mechanism
> (domain building, suspension, migration, etc.) is really inside the
> underlying libraries (xc, xutil).  The only vaguely dependent thing i
> can think of that isn't masked by these libraries is the shared memory
> interface ot the control rings accessed through xcs.  This isn't a
> very big deal though.
>  
> > 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.?
> 
> We have had some discussion about this, and Mike Wray has written some
> design documentation on the new store plan.  I think the principle
> goal of the store is to encapsulate all of the state relating to the
> currently running set of VMs in a single place, that has clear API for
> access.  Our basic view of this at the moment is a hierarchical set of
> key-value pairs that looks remarkably like a file system. ;)


Could we see Mike Wray's design documentation for the new store? 


> Having the store worked in properly should 1. make rebooting dom0 with
> active VMs unaffected more possible, 2. make adding new functionality
> (e.g. new split device types) more straightforward, and 3. make
> writing tools that need state information, and 4. scaling control up
> to a cluster all a lot more tractable.
> 
> Including more long-lived stuff like config files seems like a
> potentially reasonable thing to do as well.
> 
> > 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.
> 
> Fantastic!  We would be happy to have the help.  We are still in the
> process of hashing out exactly what the new interfaces should look
> like and how to go about moving to a new set of tools, potentially for
> the 3.0 release.  Probably the best way forward is for us to post
> design sketches to the list as they become available, and iteratively
> move towards bits of work that people can bite off.  Any specific
> ideas that you guys want to throw in now would be more than welcome as
> well.


Do you have an outline of what the new set of tools will be? It's been
mentioned that xcs will make way for multiple management apps rather
than just xm/xend. I'm curious to know what you've outlined so far for
management apps. 

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