auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto vmbr0
iface vmbr0 inet statitc
address 10.100.20.86
netmask 255.255.255.0
gateway 10.100.20.1
bridge_ports none
bridge_stp off
bridge_fd 0
For this configuration, your vmbr0 is not connected to any real network interface, so virtual machines cannot see the outside world. By adding eth0 to bridge ports, you will allow the bridge to talk to the outside world directly.
If you setup bridge_ports eth0 in the example above (pretty sure this is default) then you can connect to the hypervisor on the address for vmbr0, you don't give eth0 an IP address, it is simply virtually connected up to your internal virtual networking. This saves your machine from having to do routing.
This means that your initial vmbr0 can be thought of like a switch with extra ports on the switch your computer is connected to, so any IPs you give will be in the same subnet and using the same gateway. Your switch will effectively think it has another switch connected to it.
If you want to have your VMs on a different network to your other machines, you may be able to route (if you can set the rest of the network up to allow it) or you may have to NAT (which will work the same way as NAT behind a linux router at home)
It sounds as though you are trying to have a DHCP server assign an IP on the same range to your VMs, so this will work fine, if you just plumb your eth0 back into the vmbr0 as a bridge port: think of it as the uplink port on your internal switch.
With only one network interface, things are pretty straight forward. It gets more hairy with multiple interfaces.
