From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ME2oI-0006Px-J9 for qemu-devel@nongnu.org; Tue, 09 Jun 2009 11:00:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ME2oE-0006OK-R2 for qemu-devel@nongnu.org; Tue, 09 Jun 2009 11:00:22 -0400 Received: from [199.232.76.173] (port=34796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ME2oE-0006OC-KT for qemu-devel@nongnu.org; Tue, 09 Jun 2009 11:00:18 -0400 Received: from mail2.shareable.org ([80.68.89.115]:41446) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ME2oD-0001W2-Sc for qemu-devel@nongnu.org; Tue, 09 Jun 2009 11:00:18 -0400 Date: Tue, 9 Jun 2009 16:00:13 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 6/7] virtio-net: Add new RX filter controls Message-ID: <20090609150012.GA3921@shareable.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090609095701.GC1480@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Alex Williamson , qemu-devel@nongnu.org, "Michael S. Tsirkin" 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. -- Jamie