From: Daniel Henrique Barboza <dhbarboza82@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