This is precisely the sort of problem that the Keir's proposal seems to
address. I've copied my comments on the proposal below; perhaps we can
discuss them further now since nobody was interested when I originally
posted them. :-)
---
Here's another general comment for discussion...
The bottom of page 18 in the Xen Roadmap proposal recommends considering
how to "export byte stream
(TCP) data between domains in a high performance fashion." For
communications that occur between domains on a single physical machine,
it would seem logical to setup a new address and protocol family within
Linux that could be used to create and manipulate stream sockets via the
standard interfaces (I'm focusing on Linux at this point, although
similar adaptations could be made to other kernels). Then, behind the
scenes, the Xen grant tables could be used to efficiently transfer
socket buffers between the domains. This should involve much less
overhead than directly connecting two network frontends or performing
other optimizations at lower layers, since it would truncate the
protocol stack and avoid unnecessary TCP-style flow control protocols.
An enhancement such as this could help to eliminate the network
dependence of some Xen management applications, particularly those that
rely on XML-RPC to communicate. For example, xm currently uses a UNIX
domain socket to communicate with Xend, which introduces an artificial
requirement that xend and xm be running in the same domain. Once XenSE
gains traction and management utilities are scattered across multiple
domains, UNIX domain sockets will no longer be adequate. Under this
scheme, stream sockets to specific domains could easily be constructed,
without regard for the network configuration on the system.
One important detail that I haven't yet resolved is how to address
inter-domain sockets. Of course, the most important component in the
address for each socket would be the domain ID. However, some sort of
port specification or pathname would also be necessary. I'm not sure
which of those options would be appropriate in this case. Port numbers
would be consistent with TCP and would probably ease the task of porting
applications based on TCP, but pathnames are more consistent with the
UNIX domain sockets used by xm and xend. Perhaps we could provide both,
using two address families associated with the same protocol family?
What other ideas have been floating around on how to accomplish
byte-stream transport between domains? Are any concrete efforts to
provide this functionality currently underway? Thanks!
Ligesh wrote:
On Mon, Aug 07, 2006 at 04:32:03PM +0300, Muli Ben-Yehuda wrote:
On Mon, Aug 07, 2006 at 07:01:30PM +0530, Ligesh wrote:
Unlike openvz where all containers can run the same executables and
largely share the same environment, in Xen domU's have nothing in
common except being able to run on the same CPU. "Running an
executable" is inherently domain-specific and thus not something that
Xen should know about.
It is evident that it is a bad design choice to let Xen be aware of the
internals of domU, but I would like to know if it can be implemented as some
sort of extra or something. Anyway, that is what would be the _ideal_ system
management scenario. What would be practical is some form a message passing
system, where a process running inside the domU can get messages directly from
the dom0 without the help of network.
Or at least we should be able to send some message to the domU
using its NAME, and not ipaddress. This would make it easy to write
scripts to automate the management, which would be difficult with
the ipaddress, since ipaddress can change at some time.
How about a simple script that given a domain's name or domain ID will
return its IP?
Is there any fool proof way to get an ip of the domU using its name? It is
possible that the domU has been configured internally with a totally different
IP from the one that has been assigned to it via the dhcp.
Thanks for your time.
--
:: Ligesh :: http://ligesh.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home