2023.1 Series Release Notes

3.0.0

Other Notes

  • The yoga release of OpenStack was the final release to support python 3.6 as a result os-vif has now dropped support for python 3.6. The final release of os-vif to support python 3.6 was 2.8.0. os-vif now requires python 3.8 and is tested with 3.8, 3.9 and 3.10. newer versions may work but will not 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 plug is 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/ovn and experience packet loss during live migrations. This is not supported on windows or when using ironic smartnic ports. This option was introduced to address bug: #1933517. When using OVN as a network backend OVN requires the OVS interface to both have an ofport-id and the neutron port uuid 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 not be 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 OVN to 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 tap device to a new bridge that is connected to the integration bridge via a patch port. This enables OVN to install the openflow rules on the integration bridge before the tap is created reducing the possibility for packet loss during a live migration. By default per port bridges are disabled and this feature is considered experimental, however it will likely be enabled by default in the future after we gain experience with how this bridge topology scales in larger deployments.

2.5.0

New Features

  • We now create entrypoints for oslo.config options to allow automated documentation and validation of the configurable options for all the plugins.

2.3.0

Bug Fixes

  • Linux kernel 5.8 changed the sysfs interface that is used to discover the interfaces used for OVS offloads for certain NIC models. This results in network plugging failure, as described in bug #1892132. This release fixes the plugging issue by properly handling the new sysfs structure.

2.2.0

Upgrade Notes

  • os-vif now uses the native ovsdb driver instead of vsctl driver. This reduces the number of privileged call that os-vif need to make and generally improves plugging performance. In future release the vsctl backend will be removed.

Deprecation Notes

  • The vsctl ovsdb driver is now deprecated for removal. The default ovsdb interface has now been updated to native. This will use the ovs python binding instead of invoking the ovs-vsctl CLI. The native backend both outperforms the vsctl backend and require no elevated privileges to configure the ovsdb. This both improves security and reduces 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 a bug #1715317, MAC ageing was disabled for the intermediate bridge created as part of the hybrid plug mechanism. During the removal of brctl, this behavior was inadvertently applied to all linux bridges created by os-vif including those used in the linuxbridge driver. As a result this can lead to packet flooding (see bug #1837252) when instances are migrated. This behavior has been reverted so that the default mac ageing is determined by the kernel and is not set when using the os-vif linux bridge plugin.

1.16.0

Security Issues

  • Prevent Linux Bridge from replying to ARP messages. It should reply only if the target IP address is a local address configured on the incoming interface and it should always use the best local address. See The ARP flux problem for more information.

1.15.0

New Features

  • Added native implementation of OVSDB API in vif_plug_ovs. Both vsctl and native APIs could be selected by setting the configuration variable ovsdb_interface. A new configuration variable, ovsdb_connection, is added. This variable defines the connection string for the OVSDB backend.

Other Notes

  • Changed default value of ovsdb_connection to “tcp:127.0.0.1:6640”, to match the default value set in Neutron project. This connection string is needed by OVSDB native interface.

  • With this release, packagers of os-vif no longer need to create a dependency on brctl. brctl is largely considered obsolete and has been replaced with iproute2 by default in many linux distributions. RHEL 8 will not ship brctl in its default repos. As part of a larger effort to remove usage of brctl from OpenStack os-vif has replaced its usage of brctl with pyroute2. This does not introduce any new requirements as pyroute2 is already a requirement.

1.14.0

New Features

  • A new set of attributes to port profiles has been introduced, namely Datapath Offload Types, with DatapathOffloadRepresentor allowing os-vif to pass the required metadata for representors conforming to the kernel switchdev representor model.

Deprecation Notes

  • The API for VIFPortProfileOVSRepresentor has been frozen pending deprecation of the class. Users should transition to setting the datapath_offload of VIFPortProfileOpenVSwitch to a DatapathOffloadRepresentor object to pass representor information.

Security Issues

  • In 1.13.0 it was reported that bug #1734320 was partially resolved by change Iaf15fa7a678ec2624f7c12f634269c465fbad930. It has since emerged that that change introduced another bug due to an interaction with libvirt. It was understood that libvirt would not recreate the ovs port if it was present on the ovs bridge when spawning a vm however on inspection of the libvirt code this is not the case. In this release we have reverted the change to os-vif and libvirt will be the only entity to create the ovs port when vif_type is set to ovs and hybrid_plug is set to false in the neutron port binding details. Bug #1734320 is not expected to be present if hybrid_plug=true or vif_type vhost-user is used on linux. On windows if hybrid_plug is false on bug #1734320 is also not expected to be present. A new mitigation to bug #1734320 will be developed for the remaining case of hybrid_plug=false on linux.

1.13.0

New Features

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

Security Issues

  • In this release an edgecase where libvirt plugged the VIF instead of os-vif was addressed. Previously if ovs_hybrid_plug was set to False in the port binding details, os-vif would only ensure the ovs bridge existed and the plugging would be done by libvirt. As a result during live migration, there was a short interval where a guest could receive tagged broadcast, multicast, or flooded traffic to/from another tenant. This vulnerability is described in bug 1734320. By ensuring that os-vif always creates the OVS port as part of vif plugging we enable neutron to isolate the port prior to nova resuming the VM on the destination node. Note that as Nova cannot rely on Neutron to send network-vif-plugged events on completion of wiring up an interface it cannot wait to receive a notification before proceeding with the migration. As a result this is a partial mitigation and additional changes will be required to fully address this bug.

  • A new config option was introduced for the OVS VIF plugin. The isolate_vif option was added as a partial mitigation of bug 1734320. The isolate_vif option defaults to False for backwards compatibility with SDN controller based OpenStack deployments. For all deployments using the reference implementation of ML2/OVS with the neutron L2 agents, isolate_vif should be set to True. This option instructs the OVS plugin to assign the VIF to the Neutron dead VLAN (4095) when attaching the interface to OVS. By setting the VIF’s VLAN to this dead VLAN number, we eliminate the small attack vector that exists for other tenants to read packets during the VIF’s bring up.

1.12.0

New Features

  • Added an abstract OVSDB API in vif_plug_ovs. All calls to OVS database will de done using this unique API. Command line implementation using ovs-vsctl was refactored as a backend for this abstract API. A new configuration variable, ovsdb_interface, is added to select the interface for interacting with the OVS database.

Upgrade Notes

  • Removed IPTools implementation. IPTools driver was implemented to avoid a bug in pyroute2 library, currently solved. This implementation was marked as “deprecated” two releases ago. IP Linux commands now use Pyroute2.

1.11.0

New Features

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

1.8.0

New Features

  • In vif_plug_linux_bridge, a new field called supported_port_profiles is added to HostVIFInfo objects. This field is a list of HostPortProfileInfo objects describing the supported port profiles for each specific VIF type. Currently this field is only being used in vif_plug_ovs.

  • In vif_plug_ovs, a new field called supported_port_profiles is added to HostVIFInfo objects. This field is a list of HostPortProfileInfo objects describing the supported port profiles for each specific VIF type. Currently two port profiles are supported: VIFPortProfileOpenVSwitch and VIFPortProfileOVSRepresentor.

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 setup There 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.