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