Difference between revisions of "XenapiVlanNetworking"
m (Text replace - "NovaSpec" to "NovaSpec") |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ||
| − | * '''Launchpad Nova blueprint''': | + | * '''Launchpad Nova blueprint''': NovaSpec:xenapi-vlan-network-manager |
* '''Created''': 16 February 2011 | * '''Created''': 16 February 2011 | ||
* '''Last updated''': 16 February 2011 | * '''Last updated''': 16 February 2011 | ||
| Line 8: | Line 8: | ||
Provide support for the vlan network manager on xenapi backends | 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 == | == Implementation steps == | ||
| − | |||
Steps for network configuration on compute node: | Steps for network configuration on compute node: | ||
| − | 1) retrieve vlan id and bridge identifier using network ref into nova DB | + | 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. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | When a new instance is created, | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 23:31, 17 February 2013
- Launchpad Nova blueprint: NovaSpec: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.
