(Difference between revisions)
Jump to: navigation, search

Network Management

Line 1: Line 1:
 +
= The big picture =
 +
 
{| class="wikitable"
 
{| class="wikitable"
 
! Area
 
! Area
Line 100: Line 102:
 
|
 
|
 
|}
 
|}
 +
 +
 +
= What Quantum has to offer =
 +
 +
* VM-network centric.
 +
* Connectivity to a variety of networking (L2) solutions (bridge, OVS, UCS, etc).
 +
* IPAM (IP Address Mmanagement, L3) for vNICs.
 +
 +
= How can this be integrated into oVirt =
 +
 +
* We can choose two options:
 +
# Replace our proprietary L2 VM-network implementation with quantum (bridge plugin can be used to obtain same functionality as today?)
 +
# Have proprietary L2 network implementations live side by side.
 +
 +
* In engine, there should be a designation of network type, either 'oVirt internal' style, or 'Quantum: OVS' (or drop the quantum?)
 +
 +
** It should be possbile to mix & match ovirt internal network with others, but not sure the others can be mixed.
 +
 +
** Some functionality, such as bond management, will have to remain in oVirt network management since it is not part of quantum API.
 +
 +
* Quantum will be installed on the oVirt-engine host machine.
 +
 +
* Plugin needs to be installed (either part of bootstrap or part of VDSM command) on the Hosts.
 +
 +
* VDSM would need to support configuration of the quantum plugin on the Hosts,
 +
 +
* VDSM would need to support sending port data to libvirt on run VM/hot-plug vNIC.
 +
 +
 +
 +
* We can utilize Quantum's IPAM for vNICs:
 +
 +
** Should we define a "subnet" entity to be under a logical network, which corresponds to Quantum's "subnet" entity?

Revision as of 09:09, 9 September 2012

The big picture

Area Action Internal impl. Quantum API Notes
Logical network Create network AddNetwork http://wiki.openstack.org/Quantum/APIv2-specification#Create_Network Quantum API accept network name returns id, needs to be persisted in the engine
Update network UpdateNetwork http://wiki.openstack.org/Quantum/APIv2-specificationv#Update_Network Quantum API updates network name, admin. state and sharing status
Delete network RemoveNetwork http://wiki.openstack.org/Quantum/APIv2-specification#Delete_Network
Attachment of network to cluster Attach to cluster AttachNetworkToVdsGroup  ?
Update attachment UpdateNetworkOnCluster  ?
Detach from cluster DetachNetworkToVdsGroup  ?
Apply networking on host Apply network SetupNetworks


Deprecated:
UpdateNetworkToVdsInterface
AttachNetworkToVdsInterface
DetachNetworkFromVdsInterface
AddBond
RemoveBond

http://wiki.openstack.org/ConfigureOpenvswitch This is specific to OVS plugin, need to figure out for other plugin types.
Commit changes on host CommitNetworkChanges  ? Perhaps same rollback mechanism used today can be used for plugin configuration as well?
vNICs on VM Templates Create vNIC on Template AddVmTemplateInterface
Update vNIC on Template UpdateVmTemplateInterface
Delete vNIC on Template RemoveVmTemplateInterface
vNICs on VMs Create vNIC on VM AddVmInterface
Update vNIC on VM UpdateVmInterface
Delete vNIC on VM RemoveVmInterface
Activate vNIC on running VM RunVm

HotPlugUnplugVmNic

http://wiki.openstack.org/Quantum/APIv2-specification#Create_Port
Deactivate vNIC on running VM StopVm (on callback)

HotPlugUnplugVmNic

http://wiki.openstack.org/Quantum/APIv2-specification#Delete_Port


What Quantum has to offer

  • VM-network centric.
  • Connectivity to a variety of networking (L2) solutions (bridge, OVS, UCS, etc).
  • IPAM (IP Address Mmanagement, L3) for vNICs.

How can this be integrated into oVirt

  • We can choose two options:
  1. Replace our proprietary L2 VM-network implementation with quantum (bridge plugin can be used to obtain same functionality as today?)
  2. Have proprietary L2 network implementations live side by side.
  • In engine, there should be a designation of network type, either 'oVirt internal' style, or 'Quantum: OVS' (or drop the quantum?)
    • It should be possbile to mix & match ovirt internal network with others, but not sure the others can be mixed.
    • Some functionality, such as bond management, will have to remain in oVirt network management since it is not part of quantum API.
  • Quantum will be installed on the oVirt-engine host machine.
  • Plugin needs to be installed (either part of bootstrap or part of VDSM command) on the Hosts.
  • VDSM would need to support configuration of the quantum plugin on the Hosts,
  • VDSM would need to support sending port data to libvirt on run VM/hot-plug vNIC.


  • We can utilize Quantum's IPAM for vNICs:
    • Should we define a "subnet" entity to be under a logical network, which corresponds to Quantum's "subnet" entity?