Re: bridges

[Ross Boylan <ross@biostat.ucsf.edu>]

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, 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.

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.

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?

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.