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

[Xen-devel] Re: Communicating with the domU from dom0 without Network

 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