Hey, that's a handful as far as I am concerned. :-) I was more interested in
the 'manageability' area, where I was looking for a fool proof method to
communicate with the VM, since the networking identification is not a reliable
mechanism to access one. But, now I realize maybe I have been a bit remiss, and
actually the serial port is a unique identifier for a domU, and can be used to
communicate with it. Inside the domU, you can have a long running server
waiting at one of the serial ports, and from the Dom0, you can communicate with
a domU using the serial port. Since everything is in software, I am sure the
communication is going to be fast--i am not privy enough with serial
communication to know if there are some real bottlenecks with the protocol or
something, but from my informal approach, I think the serial port should
actually work fine. Even the ip address can be configured remotely in this
fashion.
I see that you are more interested in the performance, and I think that is a
cool idea, though implementing the protocols for different Operating systems
would be non-trivial. You will need to make kernel changes, and that would mean
that you have to have drivers, which should be specifically loaded into the
domU Operating system, and then you will have to maintain all the drivers for
each OS. Secondly, the question is how ubiquitous Xen is going to be. If every
single computer is going to have Xen, then such a method would actually yeild a
lot of practical benefits. I guess we have to compare the overheads of writing
and maintaining a new protocol for MANY operating systems to the efficiency
derived in the long term.
Anyway, I am just curious. Won't an extra serial port actually solve all the
problems that you are intending to solve using tcp like communication? Is there
any limitation to serial port communication, especially since everything is
happening in software?
Thanks.
--
:: Ligesh :: http://ligesh.com
On Mon, Aug 07, 2006 at 12:18:55PM -0400, Michael LeMay wrote:
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home