Tag Archives: network

How to create VLAN trunks and access ports for VMs on Linux bridges using NetworkManager (and have them talk)

TL;DR instead of creating a VLAN on a physical interface (like bond0.123), then turning that into a bridge for a VM, create a tagged interface on the main bridge (e.g. br0.123) and then add that into a new bridge for a VM.

Create a new bridge for the VLAN.

nmcli con add ifname br-123 type bridge con-name br-123
nmcli con modify br-123 ipv4.method disabled ipv6.method ignore
nmcli con up br-123

Create the VLAN on existing bridge (assuming br0 already exists) and attach to the new bridge (br-123).

nmcli con add type vlan con-name br0.123 ifname br0.123 dev br0 id 123
nmcli con modify br0.123 master br-123 slave-type bridge
nmcli con up br0.123

This will allow two VMs on the same host to talk to each other over the VLAN, where one is using a tagged interface on br0 (as a trunk) and the other is using br-123 (as an access port or native for VLAN 123).

+------+  +-------+                  +------------------+
| eth0 |--|       |                  |       VM1        |
+------+  |       |   +----------+   |   +----------+   |
          | bond0 |---|   br0    |---|---| eth0.123 |   |
+------+  |       |   | (bridge) |   |   |  (VLAN)  |   |
| eth1 |--|       |   +----------+   |   +----------+   |
+------+  +-------+        |         +------------------+
                           |                       +------------------+
                           |                       |       VM2        |
                      +---------+   +----------+   |   +----------+   |
                      | br0.123 |---|  br-123  |---|---|   eth0   |   |
                      | (VLAN)  |   | (bridge) |   |   | (native) |   |
                      +---------+   +----------+   |   +----------+   |

Some background

A common method for connecting VMs to a real network is to attach them to a bridge. In this case, a bridge is created on the KVM host and a physical interface is attached to it. Network interfaces of the VMs are then attached to that bridge and they are directly on the same network as the host (we’ll call this a flat network).

+------+  +-------+                  +----------------+
| eth0 |--|       |                  |       VM       |
+------+  |       |   +----------+   |   +--------+   |
          | bond0 |---|   br0    |---|---|  eth0  |   |
+------+  |       |   | (bridge) |   |   | (flat) |   |
| eth1 |--|       |   +----------+   |   +--------+   |
+------+  +-------+                  +----------------+

That’s great, but now they’re also connected to everything else on the network and maybe you didn’t want that. One solution to this is to use VLANs to put VMs on isolated networks.

The bridge mentioned above could also be used as a trunk, which can carry tagged VLAN traffic that the VM creates (assuming the physical switch is configured to accept those VLANs). In this instance, the VM would create a VLAN on its network interface and tagged traffic will flow out of the bridge onto the physical network, letting that VM talk to other VMs or devices on that same VLAN.

Continue reading

Configuring QEMU bridge helper after “access denied by acl file” error

QEMU has a neat bridge-helper utility which allows a non-root user to easily connect a virtual machine to a bridged interface. In Fedora at least, qemu-bridge-helper runs as setuid (any user can run as root) and privileges are immediately dropped to cap_net_admin. It also has a simple white/blacklist ACL mechanism in place which limits connections to virbr0, libvirt’s local area network.

That’s all great, but often you actually want a guest to be a part of your real network. This means it must connect to a bridged interface (often br0) on a physical network device.

Continue reading

NetworkManager 0.8 to arrive shortly

According to Phoronix, NetworkManager 0.8 has been flagged in the git repository and will be on the way shortly!

NetworkManager, the free software project that’s backed by Red Hat and used by many distributions for easily managing network connections
from the Linux desktop, is ready for its version 0.8 milestone. NetworkManager 0.7 is getting old and while NetworkManager 0.7.1 brought some improvements last year, the 0.8 release is rather exciting

Major improvements are better bluetooth support, integration with ModemManager, ipv6, and the removal of HAL (due to its deprecation).

Ubuntu does it again..

So I’ve foolishly upgraded a machine at work to Karmic and after a reboot, networking was completely broken.

Awesome. Why does Ubuntu break every time you upgrade? It gives “Linux” a bad name.

Looks like it’s a problem with the dhcpcd script. When running dhcpcd eth0, it errors saying that eth0 does not exist, when indeed it does.
Calling dhcpcd-bin eth0 works correctly.

Removing dhcpcd with –purge and re-installing it fixed the problem.


Just have a look at the release notes for some impressive 40+ bugs. File corruption on large files (over 512MB! Woh!), Hibernation broken, Jockey awesomeness, broken RAID, X server crash with Wacom table, blah, blah, blah. Then there’s all the others which surface when every poor sod running Jaunty tries an upgrade..

Ubuntu, where stable != stable.