From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQUAl-0007pD-D4 for qemu-devel@nongnu.org; Mon, 13 Jul 2009 18:38:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQUAg-0007p1-Dc for qemu-devel@nongnu.org; Mon, 13 Jul 2009 18:38:58 -0400 Received: from [199.232.76.173] (port=39536 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQUAg-0007oy-8j for qemu-devel@nongnu.org; Mon, 13 Jul 2009 18:38:54 -0400 Received: from mail2.shareable.org ([80.68.89.115]:53912) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MQUAf-000536-RU for qemu-devel@nongnu.org; Mon, 13 Jul 2009 18:38:54 -0400 Date: Mon, 13 Jul 2009 23:38:32 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] bidirectional data exchange between guest and host without network Message-ID: <20090713223832.GD28136@shareable.org> References: <59673.89.3.148.243.1246956346.squirrel@webmail.aql.fr> <20090707090213.GB5690@shareable.org> <53352.89.3.148.243.1246972290.squirrel@webmail.aql.fr> <20090707141204.GL15751@csclub.uwaterloo.ca> <20090707143925.GA14392@shareable.org> <42816.89.3.148.243.1247047400.squirrel@webmail.aql.fr> <20090708135722.GB21508@shareable.org> <42331.89.3.148.243.1247125873.squirrel@webmail.aql.fr> <20090711000400.GG30322@shareable.org> <20090712090220.GA17003@amd.home.annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090712090220.GA17003@amd.home.annexia.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Lennart Sorensen , Anthony Lannuzel , qemu-devel@nongnu.org, Paul Brook 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