From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cam Macdonell Subject: Re: bridges Date: Thu, 07 May 2009 13:19:48 -0600 Message-ID: <4A033454.30907@cs.ualberta.ca> References: <1241711823.5366.47.camel@corn.betterworld.us> <4A03169C.60301@cs.ualberta.ca> <1241718500.5366.70.camel@corn.betterworld.us> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Ross Boylan Return-path: Received: from fleet.cs.ualberta.ca ([129.128.22.22]:33857 "EHLO fleet.cs.ualberta.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753016AbZEGTT4 (ORCPT ); Thu, 7 May 2009 15:19:56 -0400 Received: from fleet.cs.ualberta.ca (localhost.localdomain [127.0.0.1]) by fleet-spampd (Postfix) with ESMTP id 7263928025 for ; Thu, 7 May 2009 13:19:49 -0600 (MDT) In-Reply-To: <1241718500.5366.70.camel@corn.betterworld.us> Sender: kvm-owner@vger.kernel.org List-ID: Ross Boylan wrote: > On Thu, 2009-05-07 at 11:13 -0600, Cam Macdonell wrote: >> Ross Boylan wrote: >>> I'm trying to understand bridging with KVM, but am still puzzled. >>> I think that the recommended bridging with TAP means that packets >> from >>> the VM will end up going out the host card attached to the default >>> gateway. But it looks to me as if their IP address is unchanged, >> which >>> means replies will never reach me. Is that correct? Do I need to >> NAT >>> the packets, or is something already doing that? >> Hi Ross, >> >> This is the place to start >> >> http://www.linux-kvm.org/page/Networking. > I saw that; it gives some recipes but I wasn't sure what their effect > was. > >> You want a public bridge. >> >> I'm not sure what "their" and "me" mean in your email. In short, >> with >> bridging each VM has its own IP and that VM can be accessed directly >> from the network. > "their" = the VM. > "me" = my host machine. > > So if the VM's are running on their own subnet, VMs do not run on their own subnet with bridged networking. >e.g., 10.0.2.* (I've > been assuming the subnet with TAP is like the one with the User Mode > Network stack in 3.7.3 of http://www.nongnu.org/qemu/qemu-doc.html) and > my host machine is on another net, e.g., 10.0.8.* then I think the > packet will go out with an IP of 10.0.2.2 (say). When some other > machine tries to reply to 10.0.2.2, the packet gets lost because the > outside network thinks 10.0.2.* is not for it. At least that's my > concern. If the return IP address on the packet were 10.0.8.44 > (supposing that's the IP of my host machine) then the packets could find > their way back. Using bridged networking is very different from the user stack. The user stack is extremely limited and slow. > > My host machine is on an internal network with a 10.* IP. The example > might be clearer if one supposed that the VM's were on a 192.168.* > network. > > I am perhaps being influenced by the fact that I don't want to ask for > more IP's, so I don't want to configure the VM's to use an IP on our > 10.0.8 network. Then you probably want to use a NAT network. A NAT setup puts all the VMs on their own network within the host machine. iptables is necessary to forward the subnet packets out to the world and back. Here is some older documentation, but not much has changed. Look at the first entry under "Advanced Networking". https://help.ubuntu.com/community/KVMFeisty > Does the TAP networking setup a whole subnet like the user mode network > stack (e.g., running a DHCP server), or is the idea that I would just > give the VM an IP on my subnet (10.0.8.*) in this example? No, bridge networking using taps (one tap per VM) and effectively sits all the VMs on the same network your host is on. You would need to get IPs from sysadmin for each VM. > If the latter is the case (I'm now suspecting it is) then I think the > solution is clear. I just stick the VM's on a private (to my machine) > subnet, like 192.168.*, and I do NAT on the packets as they go out. NAT is a very common solution. Use VDE (vde.sourceforget.net) to create a virtual switch on your host for the VMs. dnsmasq can serve dynamic IPs to the VMs on their own subnet that doesn't bother your sysadmin at all. Use iptables to forward and receive packets through your host's NIC. Cam