Host-managed VLANs 3.0

Network isolation provided through host-managed VLANs. This hook will create a bridge for each OpenNebula Virtual Network and attach an VLAN tagged network interface to the bridge. This mechanism is compliant with IEEE 802.1Q.

The VLAN id will be the same for every interface in a given network, calculated by adding a constant to the network id. It may also be forced by specifying an VLAN_ID parameter in the network template.

inlinetoc

Requirements

  • A network switch capable of forwarding VLAN tagged traffic and the physical switch ports should be VLAN trunks.

Considerations & Limitations

This hook require some previous work on the network components, namely the switches, to enable VLAN trunking in the network interfaces connected to the OpenNebula hosts. If this is not activated the VLAN tags will not get trough and the network will behave erratically.

Since this functionality is provided through a hook it won't be effective after a migration since the hook won't be triggered again in the target host.

Configuration

External Component Configuration

  • sudoers configured so oneadmin can execute vconfig, brctl and ip in the worker nodes.
  • vconfig package installed in the worker nodes.
  • load module 8021q

To enable VLAN (802.1Q) support in the kernel, one must load the 8021q module: <xterm> $ modprobe 8021q </xterm>

If the module is not available, please refer to your distribution's documentation on how to install it. This module, along with the vconfig binary which is also required by the script, is generally supplied by the vlan package.

OpenNebula Configuration

To activate the hook, uncomment the following snippet in oned.conf:

VM_HOOK = [
    name      = "hm-vlan",
    on        = "PROLOG",
    command   = "vnm/hm-vlan",
    arguments = "$TEMPLATE",
    remote    = "yes" ]

Usage

Once the hook is activated in oned.conf it will be automatically applied to every Virtual Machine. However this hook requires an special configuration in the Virtual Machine template. The attribute PHYDEV must be defined in the VNET template, with the name of the physical network device that must be attached to the bridge. The BRIDGE attribute is not mandatory. If it isn't defined, OpenNebula will generate one automatically.

NAME = "hmnet"
TYPE = "fixed"
PHYDEV = "eth0"
VLAN_ID = 50 # optional
BRIDGE = "brhm" # optional

LEASES = ...

In this scenario, the hook will check for the existence of the brhm bridge. If it doesn't exist it will be created. eth0 will be tagged (eth0.<vlan_id>) and attached to brhm (unless it's already attached).

:!: Any user with Network creation/modification permissions may force a custom vlan id with the VLAN_ID parameter in the network template. In that scenario, any user may be able to connect to another network with the same network id. Techniques to avoid this are explained under the Tuning & Extending section.

Tuning & Extending

Calculating VLAN id

The vlan id is calculated by adding the network id to a constant defined in /var/lib/one/remotes/hooks/vnm/OpenNebulaNetwork.rb:

CONF = {
    :start_vlan => 2
}

You can customize that value to your own needs.

Restricting manual the VLAN_ID

You can either restrict permissions on Network creation with ACLs or you can entirely disable this feature by modifying the source code of /var/lib/one/remotes/hooks/vnm/HostManaged.rb. Change these lines:

                if nic[:vlan_id]
                    vlan = nic[:vlan_id]
                else
                    vlan = CONF[:start_vlan] + nic[:network_id].to_i
                end

with this one:

                vlan = CONF[:start_vlan] + nic[:network_id].to_i