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

[Andrew Warfield <andrew.warfield@xxxxxxxxx>]

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. ;)

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.

sound okay?

a.


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