[ovs-dev] [PATCH 0/4] ovn: Schema modification for DPDK/userspace tunneling support in OVN-Openstack integration.

Russell Bryant rbryant at redhat.com
Wed Aug 26 19:03:37 UTC 2015

On 08/26/2015 11:04 AM, Chandran, Sugesh wrote:
> HI Russel,
> Please find the work flow as below.
> 1.	A user requests nova to boot a vm
> 2.	Nova schedules the vm based on the flavor and image properties to a host
> 3.	Nova asks neutron to bind the neutron port basing the selected host name and some limited information in binding profile.
> 4.	The neutron network driver(ML2/OVN driver)  that manages the selected node will then bind the port and select the vif type to use.
> 5.	Nova reads the vif type selected by neutron and generates the Libvirt xml accordingly and boots the vm.
> a.	For the normal interface nova plug the vhost-net interface to the OVS.
> b.	In the dpdk case  during the boot process nova plug the  vhost user interface into ovs
> The VIF type(kernel vhosts/vhost-user/sriov) must be decided at step
> 4 based on the capabilities of specific compute node to allow nova to
> generate the correct Libvirt xml. Nova doesn’t know the capabilities
> of selected compute node to decide what VIF type to be used in the
> libvirt XML. It’s responsibility of Neutron to provide this
> information because Nova is not supposed  to have any logic for
> manage the network. Neutron can talk only to the OVN NorthDB and this
> patch series will expose the relevant compute node details all the
> way up-to Northbound_DB. So Neutron can then instruct Nova to boot VM
> with right VIF type using the exposed information in the Northbound
> DB.
> Since OVN is taking care of entire cloud network management, we feel
> that its responsibility of OVN to provide enough information to
> Nova->Hypervisor for booting the VM with right parameter set.

Are you on the openstack-dev mailing list?  We should probably move the
conversation over there at this point.  I can post something there.  I
realize all of this isn't specific to using dpdk, but this interaction
seems more complicated than necessary.  I'd like to see if we can
simplify it, instead.

Russell Bryant

More information about the dev mailing list