43
edits
Changes
m
no edit summary
All routes to containers will be through this bridge and containers can communicate with each other even without these routes.
=== Automating the bridge ===
The most convenient method is to automatically create the bridge at boot as a network interface, add the physical interface from [[CT0]] and then add the interface from each [[CT]] as it starts. All devices are connected to a virtual switch, and containers directly access the network just as any other host without additional configuration on [[CT0]].
In Debian, configure the network interface on [[CT0]] to be a bridge in /etc/network/interfaces.
<pre>
iface eth0 inet manual
auto vzbr0
iface vzbr0 inet static
bridge-ports eth0
address 192.168.1.100
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.254
</pre>
Follow the steps below for making a veth bridge persistent with the included script. That will automatically add each container to the bridge when it is started. Finally, specify vzbr0 as the bridge when adding the network interface to a container, as describe above. No configuration is needed on [[CT0]] for forwarding packets, proxy arp or additional routes. The interface in each [[CT]] can be configured as desired. Everything "just works" according to normal network interface configuration and default routing rules.
=== Making a veth-device persistent ===
These steps are no longer necessary, as the veth device is automatically created when the container is started. They remain here as a reference.
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"
Like the above example, here it is how to add the veth device to a bridge in a persistent way.
vzctl include includes a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.
Just create /etc/vz/vznet.conf containing the following.
