Hyper-V VIF for Open vSwitch

Registered by Alessandro Pilotti on 2014-10-21


Thanks to the Open vSwitch (OVS) porting to Hyper-V, it's now possible to employ a common SDN solution across different hypervisors (e.g. KVM, Hyper-V, ESXi) in a single OpenStack deployment.

Enabling OVS on Hyper-V consists in adding a simple VIF driver to the Nova Hyper-V compute driver responsible for creating the OVS port and the related association with the Hyper-V virtual switch port.

Subsequent flow rules configurations can be performed via the OVSDB protocol either by an external controller when used in conjunction with the NSX or OpenDaylight Neutron plugins / mechanism drivers or by a local Neutron L2 OVS agent in the case of the Neutron OVS plugin.


A preliminary implementation is available at [1].

The VIF driver can inherit from the HyperVBaseVIFDriver class, following an approach similar to the existing nova-network and Neutron Hyper-V VIF drivers. The implementation is completely decoupled from the Nova driver. The specific VIF class to be used can be specified through a config option in the [hyperv] section of nova.conf.

The associated OVS ports must be created when new virtual NICs attached and during the migration / live migration of an instance to other hosts.

The associated OVS ports must be deleted when virtual NICs are detached and after a migration / live migration.


The only relevant dependency is the OVS Hyper-V port. See [2] and [3].

This feature does not depend on any Neutron component to be fully functional.


Testing will be performed by the Hyper-V CI.
No additional Tempest tests are needed.


Neutron OVS plugin's L2 agent Hyper-V porting:


[1] https://github.com/gabriel-samfira/nova/commit/8cc3cf4e2e2aa6a686f35530b78ac699d46883ec
[2] https://github.com/openvswitch/ovs
[3] http://www.cloudbase.it/open-vswitch-on-hyper-v

Blueprint information

Michael Still
Alessandro Pilotti
Gabriel Samfira
Series goal:
Accepted for ocata
Milestone target:
milestone icon ocata-3
Started by
Alessandro Pilotti
Completed by
Matt Riedemann

Related branches



Before approving this, we would need a few more details on test commitments, and the neutron dependencies should be approved, and we should the use of the existing neutron interface, etc. --johnthetubaguy 30th October 2014

Blueprint details added. There are no dependencies requirements on the Neutron side for the NSX and OpenDaylight use cases, since the related Neutron plugins / agents will manage the Hyper-V compute hosts remotely via OVSDB. -- alexpilotti 23rd November 2014

Trivial approval at Nova meeting 4 December 2014 -- mikalstill

Not enough positive reviews on this code for it to make kilo-1, moving to kilo-2 --johnthetubaguy 17th December 2014

Sorry, we have now hit the non-priority feature freeze for kilo. Please resubmit your spec for the L release. --johnthetubaguy 5th Feb 2015

Reapprove for liberty --johnthetubaguy 16th April 2015

Sorry, we have now hit the non-priority feature freeze for Liberty. You will need to resubmit this blueprint for Mitaka or apply for an exception. For more details on why this is happening, and the rest of the process details, please see: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule
--johnthetubaugy 4th August 2015

Reapprove for mitaka --johnthetubaguy 7th October 2015

Pending patches

Gerrit topic: https://review.openstack.org/#q,topic:bp/hyper-v-ovs-vif,n,z

Addressed by: https://review.openstack.org/140045
    Add Hyper-V OVS ViF driver

Addressed by: https://review.openstack.org/179727
    Moves OVS related code to a common location

Gerrit topic: https://review.openstack.org/#q,topic:bp/hyper-v-vnic-hot-plug,n,z

As the code is not ready for review, removing this blueprint from mitaka, as part of the non-priority Feature Freeze. For more details please see: http://docs.openstack.org/developer/nova/process.html --johnthetubaguy 2015.01.15

Addressed by: https://review.openstack.org/328772
    Hyper-V: Converts vifs to os-vif objects

Re-approved for Ocata as a specless feature parity blueprint for Hyper-v. -- mriedem 20160923


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.