Mailing List Archive

Fwd: [Openstack] OpenStack Quantum plugins
---------- Forwarded message ----------
From: hitesh wadekar <hitesh.wadekar@gmail.com>
Date: Sun, Apr 29, 2012 at 3:01 PM
Subject: Re: [Netstack] [Openstack] OpenStack Quantum plugins
To: Salman Malik <salmanmk@live.com>, netstack@lists.launchpad.net,
openstack@lists.launchpad.net
Cc: Dan Wendlandt <dan@nicira.com>


Hi Salman,

I think Dan explained pretty well, which will be covered all the
quantum thoughts that you have asked me. There might be some code
changes are going to happen for Folsom design feature implementation.

Also, please have a look at here,

1. http://wiki.openstack.org/QuantumAPIUseCases
2. http://qconlondon.com/dl/qcon-london-2012/slides/SalvatoreOrlando_QuantumVirtualNetworksForOpenStackClouds.pdf
3. http://www.slideshare.net/danwent/quantum-folsom-summit-developer-overview
4. http://www.slideshare.net/danwent/openstack-quantum-intro-os-meetup-32612


If you go to Salvatore's 'Inside_Quamtum' 'slide, It provides quite a
good deal of details concerning about How the nova interacts with
Quantum.

On the VIF driver side, that is a piece which runs in the nova address
space, and tells VM being spawned how their VIF should be plugged into
networks. There are VIF drivers for Quantum as well as VIF drivers for
the other network managers. VIF drivers can be both plugin and
hypervisor specific. For instance, nova/virt/<hypervisor_driver>/vif
(e.g.: nova/virt/xenapi/vif).

For OVS and more on Network, please refer this link,
http://openvswitch.org/support/, go for

1. J. Pettit, J. Gross “Open vSwitch Overview,”
2. S. Horman, “An Introduction to Open vSwitch,”

If you want to see advance networking virtualization, refer these papers,

1. J. Pettit, J. Gross, B. Pfaff, M. Casado, S. Crosby, “Virtual
Switching in an Era of Advanced Edges,”
2. B. Pfaff, J. Pettit, T. Koponen, K. Amidon, M. Casado, S. Shenker,
“Extending Networking into the Virtualization Layer,”

I hope these will help. I am also exploring the code :) (still learner)

Thanks,
Hitesh

On Sun, Apr 29, 2012 at 2:41 AM, Dan Wendlandt <dan@nicira.com> wrote:
>
>
>
> On Fri, Apr 27, 2012 at 4:44 PM, Salman Malik <salmanmk@live.com> wrote:
>>
>> Hi Dan,
>>
>> Thanks for replying. There are few more questions:
>>
>>
>>
>> I am trying to learn the functionality of Quantum plugins used in OpenStack. I have read through the Quantum Admin Guide and had few basic/quick question about quantum and OVS interaction with it:
>>
>>
>> 1) OVS can have ports in which vNICS can be plugged, so why does it need to use an integration bridge for connecting all VMs on the same node to a network?
>>
>>
>> I'm not sure I follow what question you're asking. When OVS is running on a host, it has one or more "bridges", and bridges have "ports". A linux device representing the vNIC must be added as a port of a bridge being managed by the Quantum plugin. We call this bridge the "integration bridge". The Quantum plugin can then configure the ports and bridges appropriately to forward traffic based on the logical model created via the Quantum API. Can you be more precise about what you're asking here?
>>
>> In short it means that the OVS is managing the linux bridges and the linux devices representing vNICs must be added to these bridges (Does Quantum manager adds these devices to bridges?).
>
>
> You have to be a bit careful here, because the linux bridge and open vswitch are two different things (you can think of open vswitch as an advanced version of the linux bridge).
>
> A driver in the Nova virt layer is actually the one who creates the linux devices that map to vNICs. For example, libvirt creates these devices as directed by the libvirt driver code: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py . This code attaches the linux device to an OVS bridge as a "port". The rest of the configuration of that port and the OVS bridge is up to the OVS plugin agent.
>
>>
>> And when you say that quantum plugin configures the ports and bridges appropriately to forward traffic, you mean that it updates the database and then quantum agent then assures the correct mapping of ports/network ids to logical networks at the switch level(by adding flow entries to vSwitch? or by adding the vNICs to right bridges, as there is one bridge per tenant's network on compute node). Right?
>
>
> Its not correct that there is one bridge per tenant network on the compute node. In the case of the OVS plugin, there is a single bridge (e.g., br-int) and different tenants are isolated based on configuration pushed down by the agent. Really the "plugin" consists of both the code running on the server, and (optionally) agents running on the compute nodes. Not all plugins require agents, for example, if they have some other way of managing the vswitch.
>
>
>>
>>
>> Thanks for the reference. I have looked at the code and just to affirm my understanding please confirm/correct/answer the following:
>> Quantum manager is responsible for configuring the network for new instances that spin up. When a tenant adds a port to his logical network the request will be forwarded to this manager by Nova and then Manager (using quantum client) would talk to quantum service/server (where can I see its code?) with the REST API. According to documentation, the quantum service is responsible for loading the plugin and passing the REST API calls to the plugin. The plugin then updates the database. Rest of the work is done by quantum agent.
>
>
> See: http://docs.openstack.org/incubation/openstack-network/admin/content/Using-dle455.html
>
> The workflow is actually that you create a VM with one or more vNICs, and as part of the VM creation process, nova-network is invoked using the allocate_for_instance RPC call. When you are running nova-network with QuantumManager, this code uses the main Quantum REST API to create ports for each vNIC. This is the code I pointed you to before: https://github.com/openstack/nova/blob/master/nova/network/quantum . Specifically, manager.py is the QuantumManager code, and quantum_connection.py and client.py are libraries used to talk to Quantum's REST API.
>
> Dan
>
>>
>> Salman
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Dan Wendlandt
>> Nicira, Inc: www.nicira.com
>> twitter: danwendlandt
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp