[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |