LibvirtVIFDrivers

Libvirt VIF Driver Enhacement

The Libvirt VIF driver implementations as present in Folsom suffer from a number of problems

• The Nova admin has to know what Quantum driver is used and configure the vif_driver to match
• Nova can only support a single VIF type for Quantum, which prevents concurrent use of different Quantum drivers with Nova
• The Nova admin is at risk of making suboptimal config choices. For example, choosing LibvirtOpenVswitchDriver instead of LibvirtOpenVswitchVirtualPortDriver for new libvirt
• The Nova admin is at risk of making nonsensical config choices. For example, choosing LibvirtOpenVswitchDriver at the same time as the Libvirt NWFilter firewall will result in non-operational firewall - they should use LibvirtHybridOVSBridgeDriver if they need firewalling to work

Current VIF Driver Impls in Folsom

As of Folsom the following VIF drivers exist

• [[LibvirtBridgeDriver]](LibvirtBaseVIFDriver). Connects VIFs to a plain Linux software bridge, whose name is provided by the network['bridge'] parameter. Configures filter parameters for nwfilter firewalling. Libvirt is allowed to auto-assign a TAP device name. Optionally creates the bridge device, and a VLAN device on the host.
• [[LibvirtOpenVswitchDriver]](LibvirtBaseVIFDriver). Connects VIFs to a OpenVSwitch bridge, whose name is set by CONF.libvirt_ovs_bridge parameter. The OVS integration is done manually and the TAP device name is based on the VIF UUID. No filter parameters are allowed.
• LibvirtHybridOVSBridgeDriver([[LibvirtBridgeDriver]], [[LibvirtOpenVswitchDriver]]). Connects VIFS to an OpenVSwitch bride, whose name is set by the CONF.libvirt_ovs_bridge parameter. The OVS integration is done using a software bridge and pair of veth devices, to allowing nwfilter firewalling to operate. The bridge/veth device names are chosen based on the VIF UUID. Libvirt is allowed to auto-assign a TAP device name.
• [[LibvirtOpenVswitchVirtualPortDriver]]([[LibvirtOpenVswitchDriver]]). Connects VIFs to a OpenVSwitch bridge, whose name is set by CONF.libvirt_ovs_bridge parameter. The OVS integration is done by libvirt and it is allowed to auto-assign a TAP device name. No filter parameters are allowed.
• QuantumLinuxBridgeVIFDriver(LibvirtBaseVIFDriver). Connects VIFs to a Quantum created software bridge, whose name is derived from the network['id'] parameter. Does not configure any network filtering. The TAP device name is set based on the VIF UUID.

The [[LibvirtBridgeDriver]] VIF is designed to work with Nova networking. The other VIF drivers are all designed to work with Quantum networking.

Planned VIF Driver Impls in Grizzly

As can be see above the current libvirt VIF drivers place a large burden on the Nova sysadmin to figure out what's right and has alot of potential to go wrong. The goal for Grizzly is to dramatically rationalize the the configuration to just two

• [[LibvirtNovaDriver]](LibvirtBaseVIFDriver) - replacement for LibvirtBridgeDriver which supports Nova network based bridges
• [[LibvirtQuantumDriver]](LibvirtBaseVIFDriver) - replacement for every other VIF driver which supports Quantum based networking

The first piece of simplification is that LibvirtOpenVswitchDriver and LibvirtOpenVswitchVirtualPortDriver can be merged, by doing a check against the libvirt version >= 0.9.11 and then choosing the right functionality.

The key to achieving the greater simplification is that Quantum is now able to provide Nova with information about what kind of network technology is in use. The mapping['vif_type'] parameter accepts five values, defined in quantum/extensions/portbindings.py

• VIF_TYPE_OVS = 'ovs' - OpenVSwitch bridge
• VIF_TYPE_BRIDGE = 'bridge' - traditional Linux bridge
• VIF_TYPE_802_QBG = '802.1qbg' - MacVTap VEPA qbg
• VIF_TYPE_802_QBH = '802.1qbh' - MacVTap VEPA qbh
• VIF_TYPE_OTHER = 'other' - unspecified

This means that Nova can (nearly) automatically figure out what to tell Libvirt to use. The remaining problem is network filtering. Some Quantum plugins may provide network filtering themselves, while in other cases Nova needs to do it using iptables/nwfilter capabilities.

As a first step, we can choose between LibvirtOpenVswitchDriver and LibvirtHybridOVSBridgeDriver based on what the libvirt firewall_driver impl is. If the impl is NoOpFirewall, then we can use the simpler OVS setup. If it the impl is anything else, then the hybridge setup must be used.

To cope with the scenario of Quantum having multiple OVS plugins, some of which can do native filtering, while others can't, Quantum needs to be able to inform nova whether filtering is applied. Nova can then categorically figure out how to construct the VIF config