On Tue, 2006-08-08 at 16:19 +0530, Ligesh wrote:
> 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.
You're right, my solution is more general and complicated than what
you're talking about. It will permit communications between multiple
DomU's, not just between Dom0 and a DomU. Keir's proposal calls for
just such a general solution, and it will certainly handle your
scenario. However, I understand your desire for something simple that
will work now; I just want to open up this more general discussion in
parallel to help keep the long-term picture in mind.
> 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.
>
There certainly are severe limitations on serial port performance. The
RS232 spec only goes to 20000 bps, but most PC serial ports can handle
up to 115,200 bps. Perhaps you could modify the drivers to handle
higher data rates, but it doesn't seem like an ideal solution. The
sockets approach is at least as familiar to Linux programmers, and
natively supports unlimited data rates.
> 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.
Very true. However, that's how the rest of para-virtualized Xen is
implemented. It's a little trickier for HVM guests. My initial
approach might involve assigning private IP addresses to each DomU that
can be addressed over the inter-domain sockets and provide an adapter
that converts between IP traffic and inter-domain traffic. Otherwise,
it might be possible to export a special network device with its own
addressing modes to the HVM guest and provide drivers to support it.
> 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.
>
Xen already includes many specialized drivers for use within
para-virtualized guests, and this would simply be one more for the
collection. For those OS's that don't have the appropriate driver it
may be possible to use an IP->interdomain adapter like that discussed
above, or they could forced to rely on regular TCP networking.
> 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?
>
I still think that a lightweight sockets interface with specialized
addressing modes would be sufficiently useful to include within Xen, but
that's what these discussions will determine. :-) Thanks for the
interesting counter-proposal, it does sound like it might satisfy your
short-term needs.
> 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