From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ME3TK-0006NF-Hh for qemu-devel@nongnu.org; Tue, 09 Jun 2009 11:42:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ME3TF-0006Fb-NT for qemu-devel@nongnu.org; Tue, 09 Jun 2009 11:42:46 -0400 Received: from [199.232.76.173] (port=41236 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ME3TF-0006FF-IS for qemu-devel@nongnu.org; Tue, 09 Jun 2009 11:42:41 -0400 Received: from gecko.sbs.de ([194.138.37.40]:16928) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ME3TE-0001kZ-UB for qemu-devel@nongnu.org; Tue, 09 Jun 2009 11:42:41 -0400 Message-ID: <4A2E82E8.6050209@siemens.com> Date: Tue, 09 Jun 2009 17:42:32 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090605204647.3355.81929.stgit@kvm.aw> <20090605204718.3355.28647.stgit@kvm.aw> <20090606204845.GC26877@redhat.com> <7162ab20906081201y4c598899mdfd5d42c42e17038@mail.gmail.com> <4A2D63EC.9040003@codemonkey.ws> <20090608192911.GA32168@redhat.com> <4A2D7CB6.5060101@codemonkey.ws> <20090609095701.GC1480@redhat.com> <20090609150012.GA3921@shareable.org> In-Reply-To: <20090609150012.GA3921@shareable.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 6/7] virtio-net: Add new RX filter controls List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org, Alex Williamson , "Michael S. Tsirkin" Jamie Lokier wrote: > Daniel P. Berrange wrote: >> Personally I'd just say the bridge config task is the management tool's >> problem to deal with. A mgmt tool UI shouldn't really need to expose >> the raw details of physical NICs, bond devices, VLAN devices & bridge >> devices to the user. Instead allow them to say 'create a network sharing >> two physical NICs on VLAN 53', and then have it automagically setup the >> neccessary individal devices behind the scenes. > > That's a nice idea, but it depends so intimately on the host's network > configuration, that it doesn't work in practice (in my experince), > except in some rather fixed configurations. > > The problem is: when you attach a bridge device, then all the host's > IP configuration has to be done on the bridge device instead of the > host's network interfaces. > > That means either: > > - Host's network configuration (outside the management tool) must > create bridges in advance (with one port) _just_ so that VM > management can attach to the bridge. It's hardly transparent. > Doesn't work at all with NetworkManager or any ordinary host > network configurations, for example. And you have to do it in > advance, not when starting VMs. > > - Or, the VM management tool must create bridges when VMs are > started, and then copy the IP configuration from the host > network interface to the bridge, and it must somehow trick the > host's DHCP client to moving to the bridge interface, etc. This > doesn't work with NetworkManager either. > > Quite possibly it's a mess because of the way Linux does bridging, but > still it is. > > I haven't found any solution which works on a laptop running > NetworkManager or other automatic network binding service. > > For servers with static IPs and simple network configuration it is > easier, and of course a VM management tool can always handle specific > cases like that, if told to. But even on servers, I find if they have > a complex host network configuration (e.g. policy routing tables), > adding bridges for the VMs is not something that can be done > automatically. > > Ideally, there would be a way to add a "bridge for VM" which hangs off > the edge of the host's networking, instead of disruptively having to > be in the middle. > > The pcap interface is close to that for ease of configurability, but a > bridge would behave better, especially with multiple VMs, and maybe > perform better. Pcap on Linux suffers from the limitation that injected packets are not visible to the host, thus guest<->host communication doesn't work. The same is true for PF_PACKET (or does libpcap actually use that internally?). Haven't analyzed the reasons in details yet, but I bet it's not solvable in user space. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux