#macvtap

http://virt.kernelnewbies.org/MacVTap

Macvtap is a new device driver meant to simplify virtualized bridged networking. It replaces the combination of the tun/tap and bridge drivers with a single module based on the macvlan device driver.

http://backreference.org/2014/03/20/some-notes-on-macvlanmacvtap/ This is a good read. Lays out the four main modes of macvtap: VEPA (virtual ethernet port aggregator), bridge, private and passthrough. It documents some commands used in the iproute2 suite to set the mode, and then explains the role of macvlan w.r.t. KVM/libvirt:

ip link add link eth2 macvlan2 type macvlan mode [private|vepa|bridge|passthru]

and how to show the mode

ip -d link show macvlan2

The main use of macvlan seems to be container virtualization (for example LXC guests can be configured to use a macvlan for their networking and the macvlan interface is moved to the container's namespace), but there are other scenarios, mostly very specific cases, like using virtual MAC addresses

More importantly is the macvtap interface

A macvtap interface is similar to a normal tap interface in that a program can attach to it and read/write frames. However, the similarities end here. The most prominent user of macvtap interfaces seems to be libvirt/KVM, which allows guests to be connected to macvtap interfaces. Doing so allows for (almost) bridged-like behavior of guests but without the need to have a real bridge on the host, as a regular ethernet interface can be used as the macvtap's lower device.

http://seravo.fi/2012/virtualized-bridged-networking-with-macvtap

Until now, the most easy way to give virtual machines LAN connectivity is to use bridges. The standard workflow is to create a bridge first (manually or from Hypervisor Networks module), then log on your hypervisor, add a physical NIC in the bridge. This needs to shut down the network, configure some stuff etc. It's pretty annoying and as libvirt doesn't manage adding/removing NICs to/from bridges, most of the time, the Archipel's Hypervisor Network module is pretty useless.

Well this time is over.

The Linux Kernel supports a new driver named "macvtap" since 2.6.34 and Libvirt supports it since 0.9.4 . Here is the definition:

"Macvtap is a new device driver meant to simplify virtualized bridged networking. It replaces the combination of the tun/tap and bridge drivers with a single module based on the macvlan device driver. A macvtap endpoint is a character device that largely follows the tun/tap ioctl interface and can be used directly by kvm/qemu and other hypervisors that support the tun/tap interface. The endpoint extends an existing network interface, the lower device, and has its own mac address on the same ethernet segment. Typically, this is used to make both the guest and the host show up directly on the switch that the host is connected to." (source)

We are happy to announce that Archipel now supports this driver. It's very easy to use. Select a hypervisor, go to the "Networks" tab, then create a network. Name it as you want, select the mode named "Bridge" or "Private", and select the forward device (eth0 for instance):

The "Bridge" mode will act like a standard bridge. The virtual machines in the network will have a standard LAN access. The "Private" mode is the same, but it won't be able to communicate to the rest of the VM on the host.

What you need to do on your hypervisor to support this feature is to load the "macvtap" driver

# modprobe macvtap

You also need to be sure the ethX you will use as forward device is not already in a bridge and you must use Libvirt 0.9.4+.

You may also notice there are more fields in the Network Edition Popover. You can now set the Inband / Outband traffic shaping! And last but not, least, we have added a manual XML editor for the networks, just like the Virtual Machine Definition: