Quantum and oVirt

Quantum and oVirt

The Quantum project provides "network connectivity as a service". oVirt provides a virtual datacenter management platform. VDSM is required by oVirt to manage the hosts and the virtual machines. This page tracks Fedora Cloud SIG's effort to integrate Quantum into oVirt.

Quantum is a standalone Network Virtualization service that is currently part of the OpenStack project. It uses a “plug-in” architecture, so that multiple technologies can implement the logical abstractions, which provides a “building block” for sophisticated cloud network topologies.

Quantum currently supports several publicly available plugins:

• Open vSwitch
• Cisco UCS/Nexus
• Linux Bridge
• Nicira Network Virtualization Platform (NVP)
• Ryu OpenFlow Controller

Integrating Quantum into oVirt enables oVirt to make use of emerging networking technologies, for example, OpenFlow, via one or more of the above mentioned plugins.

This page will address the following:

• Gaps and Limitations
• Proof of Concept
• Moving Forward

Gaps and Limitations

The current Quantum model has a number of gaps and limitations with respect to integration with oVirt. These are:

• Networking support
  • MTU support
  • Port mirroring
  • Permissions and ownership
  • SLA's
• Product specific issues
  • Versioning, backward compatibility
  • Ability to support a heterogeneous data center:
    • Non-uniform connectivity (i.e. not all computing resources can access the same physical networks)
    • Non-uniform technology (i.e. different plugins)
  • Security and authentication
  • Database support
  • Scalability and high availability
  • Error handling

Some of the above mentioned issues were addressed at the OpenStack Summit.

Proof of Concept

A POC integrated Quantum into oVirt and VDSM. The following plugins were tested:

• Open vSwitch
• Linux Bridge

The setup

has two appliances:

• oVirt Engine with Quantum Service and Quantum plugin. This appliance has two network interfaces:
  • em1 for management
  • p2p1 for data traffic.
• VDSM with Quantum Agent. This appliance has three network interfaces:
  • em1 for management
  • p2p1 is used temporarily to connect the oVirt network
  • p2p2 is used by the Quantum Agent

Implementation Details

oVirt Engine: A logical network has a prefix "Q_" is treated as a Quantum network. All interface with the Quantum Service is done via a script invoked from the oVirt Engine. The script makes use of the Quantum CLI commands. The script does the following:

• Creates and deletes Quantum networks. This is done when the user creates or deletes a logical network.
• Creates and deletes Quantum ports and interfaces. This is done when a user starts or stops a VM. When a Quantum network is used for VM deployment, then the RCP-XML is updated to include the quantum UUIDs. This includes the following:
• plugin
• q_network_id
• q_port_id
• q_attachment_id

VDSM: When VDSM receives a command to start a VM, if the RCP-XML contains a network with a "plugin" field then this indicates that it is a quantum network. VDSM makes use of the above mentioned RPC details to create the relevant Quantum interface. Currently a tap device is created from the "q_attachment_id" and is set as "up". In the case of the OVS plugin this is added to the integration bridge. The Quantum agent in turn will set the tags. When a VM is stopped the the tap devices will be removed form the integration bridge and deleted.

Quantum: No changes

The POC was done with F16. The latest versions for oVirt and VDSM were used. The latest Quantum and Open vSwitch Fedora packages were used.

Note
In the process of uploading the POC code changes for oVirt and VDSM. If you would like the code then please email me

Integration Issues

oVirt Engine:

• Management of the Quantum UUIDs
• Host NIC assignment
• Quantum enables a vNic to be assigned to a different network at run time - this can now be enabled by oVirt, that is, for oVirt to add or edit a NIC, the VM has to be stopped)

VDSM:

• The tap device created uses an "ethernet" network device. This requires https://bugzilla.redhat.com/show_bug.cgi?id=770020.
• Open vSwitch - a OVS database maintains all of the attached interfaces. If the node is rebooted then these interfaces will still be present in the database after reboot even though the tap devices no longer exist.

Moving Forward

At the moment the Quantum service interface is done via an external script. This needs to be integrated into the oVirt engine. This requires the following:

• JSON client for interfacing with the Quantum service
• Maintaining the Quantum UUIDs

The management and configuration of the Quantum networks by oVirt needs to be addressed in more detail.