• XenapiVlanNetworking

• Launchpad Nova blueprint: xenapi-vlan-network-manager

• Created: 16 February 2011

• Last updated: 16 February 2011

• Drafter: Salvatore Orlando

Goal

Provide support for the vlan network manager on xenapi backends

Summary

This blueprint does not propose any change to the network node. It will change the way in which the network is set up on the compute node, using XenAPI calls in place of linux commands for setting up vlans and bridges. In the current libvirt implementation both the network and the compute service use the same network driver (linux_net). In order to provide XenAPI support we need a new network driver (which implements only ensure_vlan_bridge). This network driver will replace brctl/vconfig calls with appropriate XenApi calls. For this reason:

• the network service will continue using the linux_net driver
• the compute service will use the new 'xenapi_net' driver

This also means that the two services will use different flags for the network driver

Implementation steps

Steps for network configuration on compute node:

• 1) retrieve vlan id and bridge identifier using network ref into nova DB 2) List existing networks, find network whose attribute 'name_label' is equal to the value of the 'bridge' column in nova db

  3.a) if network is not found: 3.b) Create a new network - use the value of the bridge column in nova_db as the name for the new network

  • NOTE: this is necessary as by default bridge name in nova db is brXXX where XXX=vlan id. Unfortunately, xenapi does not allow for assigning arbitrary names to bridges - xapiXXX is used.

  3.c) find the PIF for the device specified by FLAGS.vlan_interface

  • NOTE: If the target is a pool there might be multiple PIFs

  3.d) Create a VLAN using the ID retrieved at step #1 and bind it to the network create in step #3.b and the PIFs retrieved in step #3.c

  4.a) if network is found: 4.b) retrieve the PIFs associated with the network 4.c) make sure VLAN tagging is enabled for each PIF and the VLAN id is the same as step#1, otherwise throw exception

When a new instance is created, networks on the xenserver backend will not be searched by bridge (as in the flat model) but by name_label. Looking for a network called brXXX will return a reference to the xapiYYY network on the xen back-end.