Mailing List Archive

Re: [Openstack] OpenStack Quantum plugins
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: [Openstack] OpenStack Quantum plugins [ In reply to ]
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
>
>