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

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


  • To: Xen-users@xxxxxxxxxxxxxxxxxxx
  • From: Arijit Ganguly <aganguly@xxxxxxxxx>
  • Date: Thu, 1 Sep 2005 23:32:31 -0400
  • Delivery-date: Fri, 02 Sep 2005 03:30:31 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H7bFD3ioxe0uej011JjWORySCRfYYbcZnztQDm1Mzn6IDqnhg5GRn1FbiIuC4+iOWYa0j5FnetYQ4SZTYWCvLtQMvk6AWGNoqeQ9QQcUIu/34hQfPcrpyFHaZzq1dEoCObw7oktDG9bhehANusWU2J3wQlaS6s3p7txl5NetAT4=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

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
> >
>

_______________________________________________
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®.