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


 *  . Connects VIFs to a plain Linux software bridge, whose name is provided by the  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.
 *  . 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.
 *  . 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.
 *  . 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.
 *  . Connects VIFs to a Quantum created software bridge, whose name is derived from the  parameter. Does not configure any network filtering. The TAP device name is set based on the VIF UUID.

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

Desired 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, in fact to eliminate it by default. There are two key aspects to the simplification process


 * 1) Understanding the libvirt VIF setup for any given network type.
 * 2) Providing details of the network type to hypervisor drivers.

Determining VIF setup process
For OpenVSwitch in libvirt there are currently three ways to setup networking


 * 1) Manual: Create OVS ports CLI tools and configure VIF using libvirt type=ethernet
 * 2) Automatic: Configure VIF using libvirt type=bridge + vport=openvswitch
 * 3) Hybrid: Create OVS ports and associated bridge device and then use libvirt type=bridge

Previously the admin must decide which of these approaches is required, but it can be determined automatically


 * If Nova firewalling is required, then the Hybrid approach should be used
 * Else if libvirt >= 0.9.11 then the automatic approach
 * Else use the manual approach

Determining when firewalling is used is reasonably straightforward - check whether the firewall_driver impl is the no-op impl. The VIF model should probably let the network service provide a flag indicating whether firewalling has been applied at the network switch level or not, to allow nova firewalling to be skipped.

Providing details of the network type
While there are a huge (probably unlimited) number of ways to configure the host networking, fortunately, there is a small, finite number of ways to connect a guest VIF to the host networking


 * 1) Bridge: traditional Linux software bridge. Required: bridge name. Optional: auto-create-bridge, auto-create-vlan, vlan-id
 * 2) OpenVSwitch: OVS software bridge. Required: bridge name, interface ID.
 * 3) 80211.qbh: VEPA qbh: Required: device name, profile ID
 * 4) 80211.qbg: VEPA qbg: Required: device name, manager ID, type ID, type ID version, instance ID

All of these options may also have an optional VIF device name.

The current nova.network.model classes do not yet provide enough of this information, so much of it is hardcoded in the VIF driver impls, or indirectly specified by the admin via global config parameters. Thus, the VIF model will be extended to allow the following parameters


 * device name (optional for all)
 * interface ID (required if vif_type == ovs)
 * profile ID (required if vif_type == 80211.qbh)
 * manager ID (required if vif_type == 80211.qbg)
 * type ID (required if vif_type == 80211.qbg)
 * type ID version (required if vif_type == 80211.qbg)
 * instance ID (required if vif_type == 80211.qbg)
 * filtered (true if network switch has applied firewall filtering)

The Network model will be expected to have the following parameters set


 * bridge (required if vif_type == ovs or bridge)
 * interface (required if vif_type == 80211.qbg or 80211.qbh)

The Quantum and Nova Network drivers will be modified to fill in all the required information for the model.

Desired Libvirt VIF drivers
With the network model fully defined as above, only a single VIF driver will be required for the vast majority of scenarios.


 * GenericVIFDriver - automatically apply configuration based on vif_type field

All existing VIF drivers will be changed to extend from GenericVIFDriver and apply a hardcoded vif_type. This is to allow for compatibility with Quantum drivers not yet updated to provide correct vif_type information. The drivers will, however, be marked deprecated for Grizzly, to be removed in the Hxxxxx release.