Quantum OpenStack network becomes more important because it gives much more flexibility to cloud users than its predecessor, Nova network. If you are interested in the details, look at the wiki page of the project. I highly recommend the videos because they were very helpful to me during my journey into the world of OpenStack Networking. Preliminary details will also explain some of the concepts mentioned in this blog -. Such as l2 agents
original work
Just after the summit in Havana, all fixes that have allowed the use of Quantum with XenServer were waiting to be approved. All the work was done by Maru Newby, with the initial patch available at the end of 2012. You can find the patch here. Unfortunately, the patch did not release Grizzly and we decided to put a lot more effort to get OpenStack Networking working with XenServer.
As I had no previous experience with Quantum, I started reading the wiki, watch the video to get some basic understanding. Right after that, I started testing the patches provided by Maru Newby.
devstack I used to set up the environment that several changes had to be made to make it easier to test Quantum. Devstack was then modified so that it does not connect to the home network for all physical interfaces, and we also get rid of the mess VLAN tagging. There is much more to do to start with devstack on XenServer easier. A plan was created to save our efforts.
Simple installation using Devstack Box
I do not want to duplicate the wiki page that describes how to install while a developer instance OpenStack Quantum. I want to show what the environment looks like.
Deployment Architecture
This will give you a glimpse of what devstack done. The most important difference is that you will have two L2 agents :.
- q-domua management openvswitch in domU, providing connectivity for dhcp
and routing components physnet1 network - q-agt management openvswitch in dom0, connecting tenants interfaces
physnet1 the network.
You might ask, what is physnet1. This network is the network of data centers, the network is available on the hypervisor, such as "OpenStack VM Network". It is not connected to any physical interfaces, so do not be confused by the phys.
Let's look at the configuration, by issueing quantum controls
net-list quantum $
shows two networks, public and private use
$ net-show quantum.
will show the details of these networks look at the private network. supplier: network_type is vlan and provider.. physical_network is physnet1 you can see what id VLAN is used in my case, private . uses VLAN 1000. These figures come from localrc file, see OVS_VLAN_RANGES variable if you want to change the range used
the configuration of the switches
the openvswitch configuration could display as:
$ sudo OVS-vsctl show
Watch the integration bridge, and note the interfaces dhcp server (qdhcp-) and the router (qrouter-). Also note, that the integration bridge has an uplink port to the bridge physnet1 - int-br-eth1
Now go to dom0, and watch the network configuration :.
# xe network-list
You should see a network with the name OpenStack VM integration network. Note the bridge and watch the configuration openvswitch:
# sudo OVS-vsctl show
This is the switch that is used by the tenant VMs. You can see a port VLAN id hang out with 4095. This is an interface that is connected to domU, but not used. It is keen to force xapi to create the bridge openvswitch underlying. It appeared that the mere creation of a network via xapi does not create the openvswitch bridge. Please note that this bridge also has an uplink port physnet1
Mapping to physnet1
Back to domU, look at the flow :.
$ sudo OVS-ofctl br-int show
And find the line that represents the uplink to the physical thread:
3 (int-br-eth1): addr: 5a: bf: 61: b5: 45: 49
And how VLANs are mapped to the physical network:
$ sudo OVS-ofctl dump br-int flow
And in my case, the private network VLAN tags with the id 1 on the domU br-int
... in_port = 3 = 1000 dl_vlan mod_vlan_vid shares = 1, NORMAL
so we expect that the port of the server dhcp and the router is labeled with VLAN 1. Run sudo OVS-vsctl show, and search for the tag :. lines to check this
Next steps
I am intentionally not covering the public network. This network is assumed to be the external network. If you look at the configuration, you find that it is mapped to physnet1 as well, but if you're looking for flows with sudo OVS-ofctl dump br ex-flow, you will not find traces of the VLAN id. You will need to start another agent to handle your br-ex bridge.
Continued ...
0 Komentar