qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>,
	Anthony Lannuzel <anthony.lannuzel@hynesim.org>,
	qemu-devel@nongnu.org, Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] bidirectional data exchange between guest and host without network
Date: Mon, 13 Jul 2009 23:38:32 +0100	[thread overview]
Message-ID: <20090713223832.GD28136@shareable.org> (raw)
In-Reply-To: <20090712090220.GA17003@amd.home.annexia.org>

Richard W.M. Jones wrote:
> On Sat, Jul 11, 2009 at 01:04:00AM +0100, Jamie Lokier wrote:
> > Anthony Lannuzel wrote:
> > > > Can you not create _another_ network device and use that?
> > > > QEMU lets you create lots of network devices.
> > >
> > > No, I do not want the guest to be able to communicate with the host
> > > network, so that is not an option.
> > 
> > So create a network device that is only used for the private
> > communication, and isolate from the rest of the host network with
> > firewall rules.
> > 
> > I'll admit that can be a lot of work, if the host has a complex
> > network, or a dynamic one where IP addresses are unpredictable.
> 
> This is precisely the reason why vmchannel is a good thing.
> 
> There is no IPv4 address you can give to the new interface which won't
> have the potential to conflict with some other IPv4 address already in
> use.  Extra network devices require special handling in firewall rules
> and changes to the configuration of every network daemon in the
> system.

A network interface with no IPv4 or IPv6 addresses assigned would
avoid most daemon problems.  Using a non-ethernet MAC type and
point-to-point would probably avoid the rest, even routing daemons,
NetworkManager and the like.  Use raw sockets over the interfaces.

Just a thought.

> If you don't add an extra network device to the guest, then you rely
> on the host and guest being on the same network, which is not always
> true.
> 
> While it's possible to configure the guest specially to avoid this,
> that doesn't look much like our promise to run any vanilla guest as a
> virtual machine.

I don't see how "any vanilla guest" can use vmchannel, since it
requires specific kernel support doesn't it, and therefore the guest
tools can only use vmchannel on new guest kernels built for it?

-- Jamie

  reply	other threads:[~2009-07-13 22:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-07  8:45 [Qemu-devel] bidirectional data exchange between guest and host without network Anthony Lannuzel
2009-07-07  9:02 ` Jamie Lokier
2009-07-07 13:11   ` Anthony Lannuzel
2009-07-07 14:12     ` Lennart Sorensen
2009-07-07 14:39       ` Jamie Lokier
2009-07-08 10:03         ` Anthony Lannuzel
2009-07-08 13:31           ` Lennart Sorensen
2009-07-11  0:01             ` Jamie Lokier
2009-07-08 13:34           ` Paul Brook
2009-07-08 13:57           ` Jamie Lokier
2009-07-09  7:51             ` Anthony Lannuzel
2009-07-11  0:04               ` Jamie Lokier
2009-07-12  9:02                 ` Richard W.M. Jones
2009-07-13 22:38                   ` Jamie Lokier [this message]
2009-07-14  5:54                     ` Richard W.M. Jones
2009-07-16  7:46     ` Amit Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090713223832.GD28136@shareable.org \
    --to=jamie@shareable.org \
    --cc=anthony.lannuzel@hynesim.org \
    --cc=lsorense@csclub.uwaterloo.ca \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).