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