2023.1 Series Release Notes

3.0.0

Other Notes

  • The yoga release of OpenStack was the final release to support python 3.6as a result os-vif has now dropped support for python 3.6. The final releaseof os-vif to support python 3.6 was 2.8.0. os-vif now requires python 3.8and is tested with 3.8, 3.9 and 3.10. newer versions may work but willnot be tested in the zed cycle.

2.6.0

Bug Fixes

  • The os-vif OVS plugin now supports using per-port OVS bridges when hybrid plugis not used. This is disabled by default and can be enabled by defining[os_vif_ovs]/per_port_bridge=True in the compute service nova.conf.This capability should only be enabled if you are deploying with ml2/ovnand experience packet loss during live migrations. This is not supportedon windows or when using ironic smartnic ports. This option was introducedto address bug: #1933517. When using OVN as a network backend OVNrequires the OVS interface to both have an ofport-id and the neutron portuuid defined in the external_ids field. When the port is plugged if[os_vif_ovs]/per_port_bridge is not enabled then the OVS port will notbe assigned an openflow port id until the tap device is created on the host.On loaded system with many flows and ports it can take a few second for OVNto detect the creation of the tap device and install the correct flows.During that interval packets can be dropped.When[os_vif_ovs]/per_port_bridge is enabled, os-vif will add the VM tapdevice to a new bridge that is connected to the integration bridge via apatch port. This enables OVN to install the openflow rules on theintegration bridge before the tap is created reducing the possibility forpacket loss during a live migration. By default per port bridges are disabledand this feature is considered experimental, however it will likely be enabledby default in the future after we gain experience with how this bridge topologyscales in larger deployments.

2.5.0

New Features

  • We now create entrypoints for oslo.config options to allow automateddocumentation and validation of the configurable options for all theplugins.

2.3.0

Bug Fixes

  • Linux kernel 5.8 changed the sysfs interface that is used todiscover the interfaces used for OVS offloads for certain NICmodels. This results in network plugging failure, as describedinbug #1892132. This release fixes the plugging issue byproperly handling the new sysfs structure.

2.2.0

Upgrade Notes

  • os-vif now uses thenative ovsdb driver instead ofvsctl driver.This reduces the number of privileged call that os-vif need to makeand generally improves plugging performance. In future release thevsctl backend will be removed.

Deprecation Notes

  • Thevsctl ovsdb driver is now deprecated for removal.The default ovsdb interface has now been updated tonative.This will use the ovs python binding instead of invokingtheovs-vsctl CLI. Thenative backend both outperformsthevsctl backend and require no elevated privileges toconfigure the ovsdb. This both improves security andreduces plug and unplug time.

2.0.0

Upgrade Notes

  • Python 2 is no longer supported. Python 3 is required.

1.17.0

Bug Fixes

  • As part of abug #1715317, MAC ageing was disabled for the intermediatebridge created as part of the hybrid plug mechanism. During the removalofbrctl, this behavior was inadvertently applied to all linux bridgescreated by os-vif including those used in the linuxbridge driver.As a result this can lead to packet flooding (see bug #1837252) wheninstances are migrated. This behavior has been reverted so that thedefault mac ageing is determined by the kernel and is not set when usingthe os-vif linux bridge plugin.

1.16.0

Security Issues

  • Prevent Linux Bridge from replying to ARP messages. It should reply only ifthe target IP address is a local address configured on the incominginterface and it should always use the best local address. SeeThe ARPflux problem formore information.

1.15.0

New Features

  • Added native implementation of OVSDB API invif_plug_ovs. Bothvsctl andnative APIs could be selected by setting theconfiguration variableovsdb_interface.A new configuration variable,ovsdb_connection, is added. This variabledefines the connection string for the OVSDB backend.

Other Notes

  • Changed default value ofovsdb_connection to “tcp:127.0.0.1:6640”, tomatch the default value set in Neutron project. This connection string isneeded by OVSDB native interface.

  • With this release, packagers ofos-vif no longer need to create adependency onbrctl.brctl is largely considered obsolete and hasbeen replaced with iproute2 by default in many linux distributions.RHEL 8 will not shipbrctl in its default repos. As part of a largereffort to remove usage ofbrctl from OpenStackos-vif hasreplaced its usage ofbrctl withpyroute2. This does not introduceany new requirements aspyroute2 is already a requirement.

1.14.0

New Features

  • A new set of attributes to port profiles has been introduced, namelyDatapathOffloadTypes, withDatapathOffloadRepresentor allowing os-vif to pass the required metadata for representors conforming to the kernel switchdev representor model.

Deprecation Notes

  • The API forVIFPortProfileOVSRepresentor has been frozen pending deprecation of the class. Users should transition to setting thedatapath_offload ofVIFPortProfileOpenVSwitch to aDatapathOffloadRepresentor object to pass representor information.

Security Issues

  • In 1.13.0 it was reported that bug #1734320 was partially resolved bychange Iaf15fa7a678ec2624f7c12f634269c465fbad930. It has since emergedthat that change introduced another bug due to an interaction withlibvirt. It was understood that libvirt would not recreate the ovs portif it was present on the ovs bridge when spawning a vm however oninspection of the libvirt code this is not the case. In this releasewe have reverted the change to os-vif and libvirt will be the onlyentity to create the ovs port when vif_type is set to ovs andhybrid_plug is set to false in the neutron port binding details.Bug #1734320 is not expected to be present if hybrid_plug=true orvif_type vhost-user is used on linux. On windows if hybrid_plug is falseon bug #1734320 is also not expected to be present. A new mitigation tobug #1734320 will be developed for the remaining case ofhybrid_plug=false on linux.

1.13.0

New Features

  • In this release the OVS plugin was extended to always plug VIFs even whenlibvirt could plug the vif. This will enable faster migration leveragingthe multiple port bindings work completed in the Rocky release.

Security Issues

  • In this release an edgecase where libvirt plugged the VIF instead of os-vifwas addressed. Previously ifovs_hybrid_plug was set toFalse inthe port binding details, os-vif would only ensure the ovs bridge existedand the plugging would be done by libvirt. As a result during livemigration, there was a short interval where a guest could receive taggedbroadcast, multicast, or flooded traffic to/from another tenant.This vulnerability is described inbug 1734320. By ensuring thatos-vif always creates the OVS port as part of vif plugging we enableneutron to isolate the port prior to nova resuming the VM on thedestination node. Note that as Nova cannot rely on Neutron to sendnetwork-vif-plugged events on completion of wiring up an interfaceit cannot wait to receive a notification before proceeding with themigration. As a result this is a partial mitigation and additional changeswill be required to fully address this bug.

  • A new config option was introduced for the OVS VIF plugin.Theisolate_vif option was added as a partial mitigation ofbug 1734320. Theisolate_vif option defaults toFalse forbackwards compatibility with SDN controller based OpenStack deployments.For all deployments using the reference implementation of ML2/OVS withthe neutron L2 agents,isolate_vif should be set toTrue.This option instructs the OVS plugin to assign the VIF to theNeutron dead VLAN (4095) when attaching the interface to OVS. By settingthe VIF’s VLAN to this dead VLAN number, we eliminate the small attackvector that exists for other tenants to read packets during the VIF’sbring up.

1.12.0

New Features

  • Added an abstract OVSDB API invif_plug_ovs. All calls to OVS databasewill de done using this unique API.Command line implementation usingovs-vsctl was refactored as abackend for this abstract API.A new configuration variable,ovsdb_interface, is added to selectthe interface for interacting with the OVS database.

Upgrade Notes

  • Removed IPTools implementation. IPTools driver was implemented to avoid abug in pyroute2 library, currently solved. This implementation was markedas “deprecated” two releases ago. IP Linux commands now usePyroute2.

1.11.0

New Features

  • A new VIF plugin,vif_plug_noop, has been added which can be used withnetwork backends that do not require any action to be performed when anetwork interface is plugged. This plugin allow for use of, for example,the generic vhost user VIF type without OVS.

1.8.0

New Features

  • Invif_plug_linux_bridge, a new field calledsupported_port_profiles is added toHostVIFInfo objects. Thisfield is a list ofHostPortProfileInfo objects describing thesupported port profiles for each specific VIF type.Currently this field is only being used invif_plug_ovs.

  • Invif_plug_ovs, a new field calledsupported_port_profiles isadded toHostVIFInfo objects. This field is a list ofHostPortProfileInfo objects describing the supported port profiles foreach specific VIF type.Currently two port profiles are supported:VIFPortProfileOpenVSwitchandVIFPortProfileOVSRepresentor.

1.7.0

New Features

  • A new port profile has been added to describe VF representors on OVS-based switches, as featured in Linux kernel 4.8 and later. This port profile can currently be used with Agilio OVS networks. It is intended to be flexible enough to be used by multiple vendors.

1.4.0

New Features

  • New port profiles have been added to describe vhostuser fast path VIFs. In particular fast path vhostuser ports can be used with ovs, linuxbridge and calico networks. Thus for each kind of network a dedicated port profile class has been defined.

  • The vhostuser vif object has been modified to add the name of the vhostuser port. Previously to this modification, it was responsibility of ovs plugin to compute such name. This should not be necessary with this new field. Because of this new field the VIFVHostUser object version has been updated accordingly (to 1.1).

  • In the ocata cycle support was added for setting the MTU of vhost-user port with ovs.

  • vhost-user MTU support enable jumbo frames to be used with vhost-user interfaces.

  • vhost-user reconnect is a new feature of qemu that allows a vhost-user frontend(e.g. qemu) to reconnect to a vhost-user backend (e.g. ovs with dpdk) in the event that backend is restarted while the interface is in use. vhost-user reconnect leverages qemu vhost-user server mode with ovs-dpdk in client mode. This configuration requires ovs 2.6 with dpdk 16.07 and qemu 2.7 or newer to function. When qemu server mode is used with older qemu versions such as 2.5, vhost-user will still function with ovs 2.6 and dpdk 16.07, however, reconnect functionality will not be available.

Bug Fixes

  • The use of contextlib and with nested statements is deprecated. “with nested” statements are not python 3 compatible as with statement now directly support context managers. The use of contextlib and “with nested” statements has been removed from all unittests in favor of the @mock decorator syntax.

Other Notes

  • vhost-user MTU support requires ovs 2.6 or newer. On older versions of ovs, the MTU request will not be made and jumbo frames are not supported.

1.1.0

New Features

  • The ovs plugin has been extended to support vhost-user interfaces. vhost-user is a userspace protocol for high speed virtual networking introduced in qemu 2.1 and first supported in ovs 2.4 with dpdk 2.0

  • The ovs plugin has been modified to ensure that the specified OVS bridge that the vif will be attached to has been created. If the OVS bridge does not exist, it will be created with the proper datapath_type.

Bug Fixes

  • The OpenVSwitch plugin was registered with an entrypoint name of “ovs”, but its describe method mistakenly reported that its name was “ovs_hybrid”. The latter has been fixed to match the registered name.

  • os-vif plugins were previously incorrectly registered in both the setup.py and setup.cfg. All plugin registration have been removed form the setup.py as they were not used and may have blocked registration of out of tree plugins.

  • The ovs plugin now handles vifs of type VIFOpenVSwitch properly. Before, it would improperly create an extraneous linux bridge and veth pair attached to the target OVS bridge.

1.0.0

Prelude

Initial release of os-vif

New Features

  • There is an object model describing the different ways a virtual network interface can be configured on the host.There is a plugin API contract defined to enable configuration of the host OS to match a desired VIF setupThere is an object model describing the plugins available on the host.Two built-in plugins provide support for Linux Bridge and OpenVSwitch integration on Linux compute hosts.