WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon

To: andrew.warfield@xxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon
From: "Ronald G. Minnich" <rminnich@xxxxxxxx>
Date: Fri, 21 Jan 2005 10:19:15 -0700 (MST)
Cc: Anthony Liguori <aliguori@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 21 Jan 2005 17:24:00 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <eacc82a4050121083937725a83@xxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <1106322956.17263.26.camel@localhost> <eacc82a4050121083937725a83@xxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx

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