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 Plugin
• Cisco UCS/Nexus Plugin
• Linux Bridge Plugin
• Nicira Network Virtualization Platform (NVP) Plugin
• Ryu OpenFlow Controller Plugin

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 Plugin
• Linux Bridge Plugin

The setup has two appliances:

• oVirt Engine + Quantum Service + Quantum OVS plugin. This appliance has two nics - em1 for management and p2p1 for data traffic.
• VDSM + Quantum OVS Agent. This appliance has three nics. em1 for management. p2p1 is used temporarily to connect the oVirt network and p2p2 is used by the Quantum agent.

Implementation Details

oVirt Engine: If a logical network has a prefix "Q_" then the network will be treated as a Quantum network. All interface with Quantum is done via a script that is invoked from the oVirt engine code (REST client in oVirt needs to be implemented). 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

VDSM: When a VM is started if it contains a "q_attachment_id" then this indicates that it is a quantum network. A tap device will be created and 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 chnages for oVirt and VDSM

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

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.