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