[Kimchi-devel] [PATCH v4] [Kimchi 0/8] Network API change + VEPA network support

[dhbarboza82 at gmail.com]

From: Daniel Henrique Barboza <dhbarboza82 at gmail.com>

v4:
- added one interface only restriction to macvtap and bridge
networks

v3:
- Lucio suggestions made: docs/API.md and 'bridge' connection
in test_template.py

v2:
- changes on the existing network backend

This patch set implements two major changes in the network
backend and API of Kimchi:

- first 4 patches: changed the API to allow networks to be created
with more than one interface

Changing 'interface' to 'interfaces' in the network backend
to allow more than one interface to be added to a network. Existing
networks that use only one interface were adapted to use 
interfaces[0] instead. UI changes were made to comply with this
change.

- last 4 patches: second version of the VEPA network patch set.

VEPA networks are somewhat similar to macvtap networks that tunnels
traffic between  VMs by using an external VEPA-enabled switch that will
process and forward the frames faster than the host
CPU/OS can do.

The UI support is similar to what we already have for the macvtap
network. ATM the UI doesn't support multiple physical devices being
assigned to a single VEPA network but the backend does. This can
be enhanced in the future with an UI patch. The idea was to have
some UI support to get the feature alive ASAP.

To create a VEPA network the process is similar to the bridge
network, allowing more interfaces to be declared in the new
'interfaces' parameter of the networks backend.

This is the XML created when adding a VEPA network using
one interface:

<network>
  <name>vepa_net</name>
  <uuid>d6a3c86b-0592-4ccf-abf0-0abb353870b3</uuid>
  <forward dev='enp0s25' mode='vepa'>
    <interface dev='enp0s25'/>
  </forward>
</network>

This is how a VM can declare a interface that belongs to this network:

    <interface type='network'>
      <mac address='52:54:00:9c:be:bd'/>
      <source network='vepa_net'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>


This is how the XML looks like when turning on the VM. Libvirt
will take care of the creation of the VEPA tunnel by using the
assigned physical interface in the network. If more interfaces
were added to the network, libvirt will do a load balance
between them and the VMs:

    <interface type='direct'>
      <mac address='52:54:00:9c:be:bd'/>
      <source network='vepa_net' dev='enp0s25' mode='vepa'/>
      <target dev='macvtap0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

Daniel Henrique Barboza (8):
  Changing network API 'interface' to array: docs and API
  Changing network API: control and model changes
  Changing network API: unit test changes
  Changing network API: UI changes
  VEPA network support: API and i18n changes
  VEPA network support - models and xmlutils changes
  VEPA network support: additional backend unit tests
  VEPA network support: UI changes

 API.json                             |  8 ++---
 control/networks.py                  |  4 +--
 docs/API.md                          | 14 ++++----
 i18n.py                              |  8 +++--
 model/networks.py                    | 65 ++++++++++++++++++++++++------------
 tests/test_mock_network.py           | 11 ++----
 tests/test_model_network.py          | 38 ++++++++++++++++++---
 tests/test_networkxml.py             | 44 +++++++++++++++++++++++-
 tests/test_template.py               | 12 ++++---
 ui/js/src/kimchi.network.js          |  5 +--
 ui/js/src/kimchi.network_add_main.js | 12 +++----
 ui/pages/network-add.html.tmpl       |  5 +--
 xmlutils/network.py                  | 10 +++++-
 13 files changed, 169 insertions(+), 67 deletions(-)

-- 
2.5.0