[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon
On Fri, 21 Jan 2005, Andrew Warfield wrote: > > 1) Change xcs to use unix domain sockets. > > 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. how will this work if we run a 256-node xen cluster (which we will be doing here for testing)? Wouldn't we want the IP socket? > 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. make sense to me, again I sure hope we can keep things so that we can put lightweight xend's on bproc slave nodes (i.e. in the end we'd like to be python-free) and control from a single front-end node via tcp. I think python-free is beyond the scope of this discussion, just thought I'd mention it -- it's a real problem to run python tools in bproc clusters. ron ------------------------------------------------------- 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 |