Jump to: navigation, search

XenServer/VLANManager

< XenServer
Revision as of 23:30, 17 February 2013 by Ryan Lane (talk | contribs) (Text replace - "__NOTOC__" to "")

XenServer and VLAN Manager

Please first read about VLAN networking in the OpenStack Manuals:

In a nutshell, when using the VLAN manager on XenServer:

  • A PIF identified either by (A) the vlan_interface flag or (B) the bridge_interface column in the networks db table will be used for creating a XenServer VLAN network. The VLAN tag is found in the vlan column, still in the networks table, and by default the first tag is 100.
  • VIF for VM instances within this network will be plugged in this VLAN network. As you said, you won't see the bridge until a VIF is plugged in it. This behaviour is the same in XS, XCP, and Kronos.
  • The 'Openstack domU', i.e. the VM running the nova network node, instead will not be plugged into this network; since it acts as a gateway for multiple VLAN networks, it has to be attached on a VLAN trunk. For this reason it must have an interface on the parent bridge of the VLAN bridge where VM instances are plugged. I realized this is quite obscure, so to cut a long story short, if vlan_interface is eth0 it must be plugged in xenbr0, eth1 --> xenbr1, and so on (on Kronos you might also end up with brwlan0).
  • Within the Openstack domU, 'ip link' is then used to configure VLAN interfaces on the 'trunk' port. Each of this vlan interfaces is associated with a dnsmasq instance, which will distribute IP addresses to instances. The lease file for dnsmasq is constantly updated by nova-network, thus ensuring VMs get the IP address specified by the layer3 network driver (nova IPAM or Melange).

With this configuration, VM instances should be able to get the IP address assigned to them from the appropriate dnsmasq instance, and should be able to communicate without any problem with other VMs on the same network and with the their gateway.

The above point (3) probably needs some more explanations. With Open vSwitch, we don't really have distinct bridges for different VLANs; even if they appear as distinct bridges to linux and xen server, they are actually the same OVS instance, which runs a distinct 'fake-bridge' for each VLAN. The 'real' bridge is the 'parent' of the fake one. You can easily navigate fake and real bridges with ovs-vsctl.

As you can see I am referring to Openvswitch only. This is for a specific reason: the fake-parent mechanism automatically imply that ports which are not on a fake bridge are trunk ports. This does not happen with linux bridge. A packet forwarded on a VLAN interfaces does not get back in the xenbrX bridge for ethX.

Configuration

The required flags are something like:

  • --network_manager=nova.network.manager.VlanManager
  • --vlan_interface=eth1
  • --network_driver=nova.virt.xenapi.vif.XenAPIBridgeDriver/XenAPIOpenVswitchDriver