[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Re: communication between dom0 and domu



Hi Arijit,

Perhaps instead of a tun/tap device, try attaching a dummy to the
bridge in dom0. You can even use multiple dummies if required with
#modprobe -o dummy1

Marcus.

Arijit Ganguly wrote:
> I think I will go with the idea of having a private network. 
> 
> I have a xen-br1 bridge that is host-only. I created a domain that has
> its VIF connected to xen-br1. Now how do I make domain0 talk to domU.
> If we have support for tun/tap, I can create  a virtual device in dom0
> and make it one of the ports of the bridge. Seems like my xen-2.0.5
> kernel doesn't have tun modules.
> 
> Any other way to establish such network based communication?
> 
> Arijit
> 
> 
> On 9/1/05, Arijit Ganguly <aganguly@xxxxxxxxx> wrote:
> 
>>By shared directory, do you mean an NFS share?
>>
>>Arijit
>>
>>On 9/1/05, Ernst Bachmann <e.bachmann@xxxxxxxx> wrote:
>>
>>>On Thursday 01 September 2005 22:11, Arijit Ganguly wrote:
>>>
>>>>All,
>>>>Is there any way we can set up a communication channel (not a TCP/IP
>>>>based network) between domain0 and unprivileged domains. This can be
>>>>useful in a way that we can write automatic configuration mechanisms
>>>>for our unprivileged VMs.
>>>
>>>From what I heard, XenFS will allow that kind of communication, for it
>>
>>will
>>
>>>be 
>>>possibe to mmap a file from it in different domains and have shared memory
>>
>>>between domains that way.
>>>But thats still far from "running commands" in a target domain, so you'll
>>
>>>still need some application to do that for you...
>>>Easiest solution for your problem would be probably a shared directory
>>
>>with
>>
>>>dom0 putting shellscripts or executables into, and domU polling that 
>>>directory, executing and deleting whatever it finds...
>>>
>>>But it'll be some time till XenFS will be available...
>>>
>>>
>>>>Illustration:
>>>>I have a domainU running on a host, which doesn;t have network
>>>>connectivity (like ssh). I just use the VM as a environment I can
>>>>issue commands and get results.  Ports on domain0 are blocked
>>>>preventing me from accessing the VM console. I do not have an account
>>>>in domain0 for security.
>>>>What can be done is running a truested software on domain0, which
>>>>takes commands and runs them inside domainU and returns me the
>>>>results.
>>>>
>>>>The bottomline is a communication channel between dom0 and domU. Any
>>>
>>>ideas?
>>>
>>>Well, if its just that you want to "jail" suspicious software started from
>>
>>>dom0 in a domU:
>>>- mount the domU FS in dom0.
>>>- put your app in it, say /bin/something
>>>- unmount domU root
>>>- patch "init=/bin/something" into your domU config file as kernel param
>>>- xm start domU
>>>- wait till timeout or shutdown of domU, xm stop it
>>>- mount domU Root FS
>>>- read results...
>>>- maybe use a modified startscript or an entry in inittab instead of the 
>>>"init=..." kernel param.
>>>
>>>
>>>If you just want to exchange some configuration data on domU, put it onto
>>
>>>domU's kernel commandline, and read it back from /proc/cmdline inside
>>
>>domU
>>
>>>But I'd still say that a private bridge between domU and dom0 (not
>>
>>connected
>>
>>>to any real network device) and running ssh on it would be a more sensible
>>
>>>method. Without routing and maybe some ebtables scripts on it, that bridge
>>
>>>would be quite secure.
> 
> I think I will go with the idea of having a private network. 
> 
> I have a xen-br1 bridge that is host-only. I created a domain that has
> its VIF connected to xen-br1. Now how do I make domain0 talk to domU.
> 
> 
>>>Did you have a look at the vserver kernel patches and tools 
>>>(http://linux-vserver.org/)? Those might be by far better suited for your
>>
>>>problem.
>>>
>>>HTH
>>>/Ernst
>>>


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.