On Fri, 2005-01-21 at 10:39, Andrew Warfield wrote:
> The original thought behind using ip sockets behind xcs was in
> planning for cluster management. Obviously there are other ways to
> map this in, I'm not terribly fussy on this point.
Yeah, I figured as much. My only reason for domain sockets is that in
the minimal configuration, I figured that domain-0 should not expose any
network sockets. I'm fine with exporting as both a domain and an ip
socket (based on a command line option).
> > 2) Add support to xcs to export ptys (storing info in the filesystem
> > much the same way xenctld does)
>
> I would much rather see xcs only handle control messages, and see the
> console stuff broken off onto a seperate split driver. ptys/ip
> sockets/whatever can then be mapped in at the backend independent of
> how the control plane works. I just chatted with keir about this, and
> he agrees that pulling console messages off onto their own rings and
> providing a separate backend for them would be a good thing.
Is this just what it sounds like?
> > 3) Change xenctld tools to use xcs.
>
> sure... although i think there is a fair bit more involved in
> create/destroy than what those tools are providing.
Oh yes. The vm-create tool does not work. I hacked it up last night
hoping that it would work for at least ramdisk-based kernels. I did not
get it to work.
> > 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?
The thought was that xcs might be something that has to be rewritten.
If ptys are not in it than I guess it doesn't really matter.
> > 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.
>
> > 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.
Great.
> 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 are the thoughts on how this will be exposed? Is this targeted for
user space or kernel space?
My thoughts along these lines was to use a directory and simulate a
/proc-like structure in user space. This has problems though.
> 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.
Indeed.
> 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.
>
> Things are a little busy here right now, so i hope this isn't too brief. ;)
If there's things we can do to help out, let us know. I'm going to
working on xcs. If you've got feature requests or anything just say
them on the list, I'm sure someone will pick it up :-)
Thanks,
> best,
> 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
--
Anthony Liguori
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@xxxxxxxxxx
Phone: (512) 838-1208
-------------------------------------------------------
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