[PATCH] [Kimchi 0/5] VEPA network support
From: Daniel Henrique Barboza <dhbarboza82@gmail.com> This patch set implements the VEPA network support for Kimchi in the backend and the frontend. VEPA networks are somewhat similar to bridge 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 bridge 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 with an extra parameter called 'vepa_devs', an array of physical devices. Let me show an example of use: 1- creating the VEPA network (can be done via the UI): [danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X POST 'https://localhost:8001/plugins/kimchi/networks' -d'{"name":"vepa_net", "connection":"vepa", "vepa_devs":["enp0s25"]}' Enter host password for user 'root': { "in_use":false, "persistent":true, "interface":"", "vms":[], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"inactive", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$ - this is the generated network XML in libvirt: [danielhb@arthas kimchi]$ sudo virsh net-dumpxml vepa_net <network> <name>vepa_net</name> <uuid>96da7b58-d655-4fa2-b0f6-d9a026cbf95a</uuid> <forward dev='enp0s25' mode='vepa'> <interface dev='enp0s25'/> </forward> </network> [danielhb@arthas kimchi]$ 2 - In Kimchi UI: - activate the network - create (or edit) a template and add this network to an interface - create a VM using that template. This is the result interface XML of the VM: <interface type='network'> <mac address='52:54:00:77:31:30'/> <source network='vepa_net'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> And this is the backend call showing the status of the 'vepa_net' network after these steps: [danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/kimchi/networks/vepa_net' Enter host password for user 'root': { "in_use":true, "persistent":true, "interface":"", "vms":[ "vepa-vm" ], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"active", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$ Daniel Henrique Barboza (5): VEPA network support: API and i18n changes VEPA network support: xmlutils changes VEPA network support: changes in networks control and model VEPA network support: additional backend unit tests VEPA network support: UI changes API.json | 2 +- control/networks.py | 5 +++-- docs/API.md | 5 +++++ i18n.py | 5 +++-- model/networks.py | 14 ++++++++++-- tests/test_networkxml.py | 42 +++++++++++++++++++++++++++++++++++- ui/js/src/kimchi.network.js | 9 ++++++-- ui/js/src/kimchi.network_add_main.js | 19 ++++++++++------ ui/pages/network-add.html.tmpl | 5 +++-- xmlutils/network.py | 25 +++++++++++++++++++-- 10 files changed, 111 insertions(+), 20 deletions(-) -- 2.5.0
From: Daniel Henrique Barboza <dhbarboza82@gmail.com> This patch includes API and message changes to support VEPA networks in Kimchi: - API.json: added 'vepa' as a valid connection in the networks API - docs/API.md: added 'vepa' as a valid connection in the networks API. A new attribute called 'vepa_devs' was created to declare one or more VEPA physical devices. - i18n.py: changed one message and added an additional message. Signed-off-by: Daniel Henrique Barboza <dhbarboza82@gmail.com> --- API.json | 2 +- docs/API.md | 5 +++++ i18n.py | 5 +++-- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/API.json b/API.json index 2b64d07..2724d21 100644 --- a/API.json +++ b/API.json @@ -353,7 +353,7 @@ "connection": { "description": "Specifies how this network should be connected to the other networks", "type": "string", - "pattern": "^isolated|nat|bridge|macvtap$", + "pattern": "^isolated|nat|bridge|macvtap|vepa$", "required": true, "error": "KCHNET0012E" }, diff --git a/docs/API.md b/docs/API.md index 01ee432..ff9159c 100644 --- a/docs/API.md +++ b/docs/API.md @@ -637,12 +637,17 @@ A interface represents available interface on host. * bridge: All traffic on this network will be bridged through a Linux bridged, which is created upon specified interface in case it is not already a Linux bridge. + * vepa: All traffic will be forward to one or more physical devices + directly connected to a VEPA-enabled switch. * subnet *(optional)*: Network segment in slash-separated format with ip address and prefix or netmask used to create nat network. * interface *(optional)*: The name of a network interface on the host. For "macvtap" and "bridge" connections, the interface can be a nic, bridge or bonding device. * vlan_id *(optional)*: VLAN tagging ID for the macvtap bridge network. + * vepa_devs *(required for VEPA)*: list of devices that composes the vepa network. + At least one device must be present. + ### Resource: Network diff --git a/i18n.py b/i18n.py index a575922..bfa85ec 100644 --- a/i18n.py +++ b/i18n.py @@ -1,7 +1,7 @@ # # Project Kimchi # -# Copyright IBM, Corp. 2014-2015 +# Copyright IBM, Corp. 2014-2016 # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -259,7 +259,7 @@ messages = { "KCHNET0009E": _("Unable to find a free IP address for network '%(name)s'"), "KCHNET0010E": _("The interface %(iface)s already exists."), "KCHNET0011E": _("Network name must be a string without slashes (/) or quotes (\")"), - "KCHNET0012E": _("Supported network types are isolated, NAT, macvtap and bridge"), + "KCHNET0012E": _("Supported network types are isolated, NAT, macvtap, bridge and vepa"), "KCHNET0013E": _("Network subnet must be a string with IP address and prefix or netmask"), "KCHNET0014E": _("Network interface must be a string"), "KCHNET0015E": _("Network VLAN ID must be an integer between 1 and 4094"), @@ -274,6 +274,7 @@ messages = { "KCHNET0025E": _("Unable to create bridge %(name)s. Details: %(err)s"), "KCHNET0026E": _("Open VSwitch bridges can only host bridged networks."), "KCHNET0027E": _("Unable to create bridge with NetworkManager enabled. Disable it and try again."), + "KCHNET0028E": _("Creating a VEPA network requires interfaces declared in 'vepa_devs' parameter."), "KCHSR0001E": _("Storage server %(server)s was not used by Kimchi"), -- 2.5.0
From: Daniel Henrique Barboza <dhbarboza82@gmail.com> Changes were made to properly process the extra 'vepa_devs' parameter in the connection='vepa' scenario. VEPA networks supports more than one physical device to be declared, allowing libvirt to balance the load between the VM interfaces that belongs to this network. Signed-off-by: Daniel Henrique Barboza <dhbarboza82@gmail.com> --- xmlutils/network.py | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/xmlutils/network.py b/xmlutils/network.py index 6fc3481..55886c0 100644 --- a/xmlutils/network.py +++ b/xmlutils/network.py @@ -1,7 +1,7 @@ # # Project Kimchi # -# Copyright IBM, Corp. 2014 +# Copyright IBM, Corp. 2014-2016 # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -77,10 +77,12 @@ def _get_forward_elem(**kwargs): return None forward = E.forward() + mode = None if 'mode' in kwargs.keys(): + mode = kwargs['mode'] forward.set('mode', kwargs['mode']) - if 'dev' in kwargs.keys(): + if 'dev' in kwargs.keys() and mode != 'vepa': forward.set('dev', kwargs['dev']) if 'managed' in kwargs.keys(): @@ -89,6 +91,19 @@ def _get_forward_elem(**kwargs): return forward +def _get_forward_with_vepa_devs(vepa_devs_param, forward): + + if len(vepa_devs_param) == 1: + forward.set('dev', vepa_devs_param[0]) + + for dev in vepa_devs_param: + interface = E.interface() + interface.set('dev', dev) + forward.append(interface) + + return forward + + def to_network_xml(**kwargs): network = E.network(E.name(kwargs['name'])) bridge = kwargs.get('bridge') @@ -104,6 +119,12 @@ def to_network_xml(**kwargs): params = kwargs.get('forward', {"mode": None}) forward = _get_forward_elem(**params) if forward is not None: + + forward_mode = forward.get('mode') + if forward_mode == 'vepa' and 'vepa_devs' in kwargs: + vepa_devs = kwargs['vepa_devs'] + forward = _get_forward_with_vepa_devs(vepa_devs, forward) + network.append(forward) if 'net' in kwargs: -- 2.5.0
From: Daniel Henrique Barboza <dhbarboza82@gmail.com> - added a new parameter 'vepa_devs' in the 'data' property of the Network Resource in control/networks.py - added 'vepa_devs' parameter to the returned dict of lookup() and a verification to invalidate the create operation if the network connection is 'vepa' and the 'vepa_devs' is None or empty. Signed-off-by: Daniel Henrique Barboza <dhbarboza82@gmail.com> --- control/networks.py | 5 +++-- model/networks.py | 14 ++++++++++++-- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/control/networks.py b/control/networks.py index fd92111..ce7ce36 100644 --- a/control/networks.py +++ b/control/networks.py @@ -1,7 +1,7 @@ # # Project Kimchi # -# Copyright IBM, Corp. 2013-2015 +# Copyright IBM, Corp. 2013-2016 # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -51,4 +51,5 @@ class Network(Resource): 'subnet': self.info['subnet'], 'dhcp': self.info['dhcp'], 'state': self.info['state'], - 'persistent': self.info['persistent']} + 'persistent': self.info['persistent'], + 'vepa_devs': self.info['vepa_devs']} diff --git a/model/networks.py b/model/networks.py index fba181f..6fb09a2 100644 --- a/model/networks.py +++ b/model/networks.py @@ -1,7 +1,7 @@ # # Project Kimchi # -# Copyright IBM, Corp. 2014-2015 +# Copyright IBM, Corp. 2014-2016 # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -92,6 +92,9 @@ class NetworksModel(object): params['forward'] = {'mode': 'bridge'} elif connection != 'isolated': params['forward'] = {'mode': connection} + elif connection == 'vepa': + if not params.get('vepa_devs') or len(params['vepa_devs']) == 0: + raise InvalidOperation("KCHNET0028E") # set subnet, bridge network do not need subnet if connection in ["nat", 'isolated']: @@ -326,6 +329,7 @@ class NetworkModel(object): dhcp = net_dict['dhcp'] forward = net_dict['forward'] interface = net_dict['bridge'] + vepa_devs = [] connection = forward['mode'] or "isolated" # FIXME, if we want to support other forward mode well. @@ -334,11 +338,16 @@ class NetworkModel(object): interface = interface or forward['interface'][0] if netinfo.is_nic(interface) or netinfo.is_bonding(interface): connection = 'macvtap' - # exposing the network on linux bridge or macvtap interface interface_subnet = knetwork.get_dev_netaddr(interface) subnet = subnet if subnet else interface_subnet + if connection == 'vepa': + vepa_devs = xpath_get_text( + xml, + "/network/forward/interface/@dev" + ) + # libvirt use format 192.168.0.1/24, standard should be 192.168.0.0/24 # http://www.ovirt.org/File:Issue3.png if subnet: @@ -347,6 +356,7 @@ class NetworkModel(object): return {'connection': connection, 'interface': interface, + 'vepa_devs': vepa_devs, 'subnet': subnet, 'dhcp': dhcp, 'vms': self._get_vms_attach_to_a_network(name), -- 2.5.0
From: Daniel Henrique Barboza <dhbarboza82@gmail.com> Added extra tests to assert the resulting VEPA network XML. Signed-off-by: Daniel Henrique Barboza <dhbarboza82@gmail.com> --- tests/test_networkxml.py | 42 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/tests/test_networkxml.py b/tests/test_networkxml.py index d4e2c3f..f455f1b 100644 --- a/tests/test_networkxml.py +++ b/tests/test_networkxml.py @@ -1,7 +1,7 @@ # # Kimchi # -# Copyright IBM, Corp. 2013-2014 +# Copyright IBM, Corp. 2013-2016 # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -153,6 +153,46 @@ class NetworkXmlTests(unittest.TestCase): self.assertEquals(netmask, str(ipaddr.IPNetwork(params["net"]).netmask)) + def test_vepa_network_singledev_xml(self): + expected_xml = """<network>\ +<name>test_vepa</name>\ +<forward mode="vepa" dev="vepa_switch_interface">\ +<interface dev="vepa_switch_interface"/>\ +</forward>\ +</network>""" + + params = { + "name": "test_vepa", + "forward": {"mode": "vepa"}, + "vepa_devs": ["vepa_switch_interface"] + } + xml_str = nxml.to_network_xml(**params) + + self.assertEqual(xml_str, expected_xml) + + def test_vepa_network_multipledevs_xml(self): + expected_xml = """<network>\ +<name>test_vepa</name>\ +<forward mode="vepa">\ +<interface dev="vepa_switch_interface1"/>\ +<interface dev="vepa_switch_interface2"/>\ +<interface dev="vepa_switch_interface3"/>\ +</forward>\ +</network>""" + + params = { + "name": "test_vepa", + "forward": {"mode": "vepa"}, + "vepa_devs": [ + "vepa_switch_interface1", + "vepa_switch_interface2", + "vepa_switch_interface3" + ] + } + xml_str = nxml.to_network_xml(**params) + + self.assertEqual(xml_str, expected_xml) + class InterfaceXmlTests(unittest.TestCase): -- 2.5.0
From: Daniel Henrique Barboza <dhbarboza82@gmail.com> Pinpoint UI changes to add a new network type named 'vepa' with the same capabilites as the bridge network. At this moment, the UI does not support multiple physical devices to be declared in the VEPA network. This will require additional UI changes in the future (no backend changes needed). Signed-off-by: Daniel Henrique Barboza <dhbarboza82@gmail.com> --- ui/js/src/kimchi.network.js | 9 +++++++-- ui/js/src/kimchi.network_add_main.js | 19 +++++++++++++------ ui/pages/network-add.html.tmpl | 5 +++-- 3 files changed, 23 insertions(+), 10 deletions(-) diff --git a/ui/js/src/kimchi.network.js b/ui/js/src/kimchi.network.js index 923aeb9..a3aea52 100644 --- a/ui/js/src/kimchi.network.js +++ b/ui/js/src/kimchi.network.js @@ -1,7 +1,7 @@ /* * Project Kimchi * - * Copyright IBM, Corp. 2013-2015 + * Copyright IBM, Corp. 2013-2016 * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. @@ -17,6 +17,7 @@ */ kimchi.NETWORK_TYPE_MACVTAP = "macvtap"; +kimchi.NETWORK_TYPE_VEPA = "vepa"; kimchi.initNetwork = function() { if(wok.tabMode['network'] === 'admin') { @@ -41,7 +42,11 @@ kimchi.initNetworkListView = function() { } else { network.type = data[i].connection; } - network.interface = data[i].interface ? data[i].interface : null; + if (network.type === kimchi.NETWORK_TYPE_VEPA) { + network.interface = data[i].vepa_devs[0] ? data[i].vepa_devs[0] : null; + } else { + network.interface = data[i].interface ? data[i].interface : null; + } network.addrSpace = data[i].subnet ? data[i].subnet : null; network.persistent = data[i].persistent; kimchi.addNetworkItem(network); diff --git a/ui/js/src/kimchi.network_add_main.js b/ui/js/src/kimchi.network_add_main.js index 0087407..f297e90 100644 --- a/ui/js/src/kimchi.network_add_main.js +++ b/ui/js/src/kimchi.network_add_main.js @@ -1,7 +1,7 @@ /* * Project Kimchi * - * Copyright IBM, Corp. 2013-2015 + * Copyright IBM, Corp. 2013-2016 * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. @@ -33,9 +33,15 @@ kimchi.startNetworkCreation = function() { name : network.name, connection: network.type }; - if (network.type === kimchi.NETWORK_TYPE_MACVTAP) { - data.connection = "macvtap"; - data.interface = network.interface; + if (network.type === kimchi.NETWORK_TYPE_MACVTAP || + network.type === kimchi.NETWORK_TYPE_VEPA) { + if (network.type === kimchi.NETWORK_TYPE_MACVTAP) { + data.connection = "macvtap"; + data.interface = network.interface; + } else { + data.connection = "vepa"; + data.vepa_devs = [network.interface]; + } if ($("#enableVlan").prop("checked")) { data.vlan_id = network.vlan_id; if (!(data.vlan_id >=1 && data.vlan_id <= 4094)) { @@ -134,7 +140,8 @@ kimchi.getNetworkDialogValues = function() { name : $("#networkName").val(), type : $("#networkType").val() }; - if (network.type === kimchi.NETWORK_TYPE_MACVTAP) { + if (network.type === kimchi.NETWORK_TYPE_MACVTAP || + network.type === 'vepa') { network.interface = $("#networkDestinationID").val(); network.vlan_id = parseInt($("#networkVlanID").val()); } @@ -151,7 +158,7 @@ kimchi.setupNetworkFormEvent = function() { var selectedType = $(this).val(); if(selectedType == 'isolated' || selectedType == 'nat') { kimchi.enableBridgeOptions(false); - } else if (selectedType == 'macvtap') { + } else if (selectedType == 'macvtap' || selectedType == 'vepa') { kimchi.enableBridgeOptions(true); } }); diff --git a/ui/pages/network-add.html.tmpl b/ui/pages/network-add.html.tmpl index 7158b75..68fe4bd 100644 --- a/ui/pages/network-add.html.tmpl +++ b/ui/pages/network-add.html.tmpl @@ -1,7 +1,7 @@ #* * Project Kimchi * - * Copyright IBM, Corp. 2014-2015 + * Copyright IBM, Corp. 2014-2016 * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. @@ -41,6 +41,7 @@ <option value="isolated">$_("Isolated: no external network connection")</option> <option value="nat">$_("NAT: outbound physical network connection only")</option> <option value="macvtap">$_("Bridged: Virtual machines are connected to physical network directly")</option> + <option value="vepa">$_("VEPA: special mode where virtual machines are connected to a VEPA-enabled switch")</option> </select> </div> <div id="networkBriDisabledLabel" class="form-group hidden"> @@ -71,4 +72,4 @@ kimchi.network_add_main(); </script> </body> -</html> \ No newline at end of file +</html> -- 2.5.0
Reviewed-by: Paulo Vital <pvital@linux.vnet.ibm.com> On 01/21/2016 11:39 AM, dhbarboza82@gmail.com wrote:
From: Daniel Henrique Barboza <dhbarboza82@gmail.com>
This patch set implements the VEPA network support for Kimchi in the backend and the frontend. VEPA networks are somewhat similar to bridge 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 bridge 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 with an extra parameter called 'vepa_devs', an array of physical devices.
Let me show an example of use:
1- creating the VEPA network (can be done via the UI):
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X POST 'https://localhost:8001/plugins/kimchi/networks' -d'{"name":"vepa_net", "connection":"vepa", "vepa_devs":["enp0s25"]}' Enter host password for user 'root': { "in_use":false, "persistent":true, "interface":"", "vms":[], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"inactive", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
- this is the generated network XML in libvirt:
[danielhb@arthas kimchi]$ sudo virsh net-dumpxml vepa_net <network> <name>vepa_net</name> <uuid>96da7b58-d655-4fa2-b0f6-d9a026cbf95a</uuid> <forward dev='enp0s25' mode='vepa'> <interface dev='enp0s25'/> </forward> </network>
[danielhb@arthas kimchi]$
2 - In Kimchi UI: - activate the network - create (or edit) a template and add this network to an interface - create a VM using that template.
This is the result interface XML of the VM:
<interface type='network'> <mac address='52:54:00:77:31:30'/> <source network='vepa_net'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
And this is the backend call showing the status of the 'vepa_net' network after these steps:
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/kimchi/networks/vepa_net' Enter host password for user 'root': { "in_use":true, "persistent":true, "interface":"", "vms":[ "vepa-vm" ], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"active", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
Daniel Henrique Barboza (5): VEPA network support: API and i18n changes VEPA network support: xmlutils changes VEPA network support: changes in networks control and model VEPA network support: additional backend unit tests VEPA network support: UI changes
API.json | 2 +- control/networks.py | 5 +++-- docs/API.md | 5 +++++ i18n.py | 5 +++-- model/networks.py | 14 ++++++++++-- tests/test_networkxml.py | 42 +++++++++++++++++++++++++++++++++++- ui/js/src/kimchi.network.js | 9 ++++++-- ui/js/src/kimchi.network_add_main.js | 19 ++++++++++------ ui/pages/network-add.html.tmpl | 5 +++-- xmlutils/network.py | 25 +++++++++++++++++++-- 10 files changed, 111 insertions(+), 20 deletions(-)
Reviewed-By: Lucio Correia <luciojhc@linux.vnet.ibm.com> On 21-01-2016 11:39, dhbarboza82@gmail.com wrote:
From: Daniel Henrique Barboza <dhbarboza82@gmail.com>
This patch set implements the VEPA network support for Kimchi in the backend and the frontend. VEPA networks are somewhat similar to bridge 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 bridge 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 with an extra parameter called 'vepa_devs', an array of physical devices.
Let me show an example of use:
1- creating the VEPA network (can be done via the UI):
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X POST 'https://localhost:8001/plugins/kimchi/networks' -d'{"name":"vepa_net", "connection":"vepa", "vepa_devs":["enp0s25"]}' Enter host password for user 'root': { "in_use":false, "persistent":true, "interface":"", "vms":[], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"inactive", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
- this is the generated network XML in libvirt:
[danielhb@arthas kimchi]$ sudo virsh net-dumpxml vepa_net <network> <name>vepa_net</name> <uuid>96da7b58-d655-4fa2-b0f6-d9a026cbf95a</uuid> <forward dev='enp0s25' mode='vepa'> <interface dev='enp0s25'/> </forward> </network>
[danielhb@arthas kimchi]$
2 - In Kimchi UI: - activate the network - create (or edit) a template and add this network to an interface - create a VM using that template.
This is the result interface XML of the VM:
<interface type='network'> <mac address='52:54:00:77:31:30'/> <source network='vepa_net'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
And this is the backend call showing the status of the 'vepa_net' network after these steps:
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/kimchi/networks/vepa_net' Enter host password for user 'root': { "in_use":true, "persistent":true, "interface":"", "vms":[ "vepa-vm" ], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"active", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
Daniel Henrique Barboza (5): VEPA network support: API and i18n changes VEPA network support: xmlutils changes VEPA network support: changes in networks control and model VEPA network support: additional backend unit tests VEPA network support: UI changes
API.json | 2 +- control/networks.py | 5 +++-- docs/API.md | 5 +++++ i18n.py | 5 +++-- model/networks.py | 14 ++++++++++-- tests/test_networkxml.py | 42 +++++++++++++++++++++++++++++++++++- ui/js/src/kimchi.network.js | 9 ++++++-- ui/js/src/kimchi.network_add_main.js | 19 ++++++++++------ ui/pages/network-add.html.tmpl | 5 +++-- xmlutils/network.py | 25 +++++++++++++++++++-- 10 files changed, 111 insertions(+), 20 deletions(-)
-- Lucio Correia Software Engineer IBM LTC Brazil
On 01/21/2016 11:39 AM, dhbarboza82@gmail.com wrote:
From: Daniel Henrique Barboza <dhbarboza82@gmail.com>
This patch set implements the VEPA network support for Kimchi in the backend and the frontend. VEPA networks are somewhat similar to bridge 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 bridge 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 with an extra parameter called 'vepa_devs', an array of physical devices.
Let me show an example of use:
1- creating the VEPA network (can be done via the UI):
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X POST 'https://localhost:8001/plugins/kimchi/networks' -d'{"name":"vepa_net", "connection":"vepa", "vepa_devs":["enp0s25"]}'
I don't see a reason to do not reuse the 'interface' parameter for this network type. I understand it can be a list of value for VEPA, but we can change it to "interfaces" and to be a list and ensure only one value is passed for brigded/macvtap network. That way we simplify the API, in terms of getting the same set of parameters to create a network.
Enter host password for user 'root': { "in_use":false, "persistent":true, "interface":"", "vms":[], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"inactive", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
- this is the generated network XML in libvirt:
[danielhb@arthas kimchi]$ sudo virsh net-dumpxml vepa_net <network> <name>vepa_net</name> <uuid>96da7b58-d655-4fa2-b0f6-d9a026cbf95a</uuid> <forward dev='enp0s25' mode='vepa'> <interface dev='enp0s25'/> </forward> </network>
[danielhb@arthas kimchi]$
2 - In Kimchi UI: - activate the network - create (or edit) a template and add this network to an interface - create a VM using that template.
This is the result interface XML of the VM:
<interface type='network'> <mac address='52:54:00:77:31:30'/> <source network='vepa_net'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
And this is the backend call showing the status of the 'vepa_net' network after these steps:
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/kimchi/networks/vepa_net' Enter host password for user 'root': { "in_use":true, "persistent":true, "interface":"", "vms":[ "vepa-vm" ], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"active", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
Daniel Henrique Barboza (5): VEPA network support: API and i18n changes VEPA network support: xmlutils changes VEPA network support: changes in networks control and model VEPA network support: additional backend unit tests VEPA network support: UI changes
API.json | 2 +- control/networks.py | 5 +++-- docs/API.md | 5 +++++ i18n.py | 5 +++-- model/networks.py | 14 ++++++++++-- tests/test_networkxml.py | 42 +++++++++++++++++++++++++++++++++++- ui/js/src/kimchi.network.js | 9 ++++++-- ui/js/src/kimchi.network_add_main.js | 19 ++++++++++------ ui/pages/network-add.html.tmpl | 5 +++-- xmlutils/network.py | 25 +++++++++++++++++++-- 10 files changed, 111 insertions(+), 20 deletions(-)
On 02/05/2016 04:55 PM, Aline Manera wrote:
On 01/21/2016 11:39 AM, dhbarboza82@gmail.com wrote:
From: Daniel Henrique Barboza <dhbarboza82@gmail.com>
This patch set implements the VEPA network support for Kimchi in the backend and the frontend. VEPA networks are somewhat similar to bridge 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 bridge 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 with an extra parameter called 'vepa_devs', an array of physical devices.
Let me show an example of use:
1- creating the VEPA network (can be done via the UI):
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X POST 'https://localhost:8001/plugins/kimchi/networks' -d'{"name":"vepa_net", "connection":"vepa", "vepa_devs":["enp0s25"]}'
I don't see a reason to do not reuse the 'interface' parameter for this network type.
I understand it can be a list of value for VEPA, but we can change it to "interfaces" and to be a list and ensure only one value is passed for brigded/macvtap network. That way we simplify the API, in terms of getting the same set of parameters to create a network.
Unless the API, the code looks good for me. I only have one more comment: don't we need to change the /interfaces to properly list the VEPA interfaces? Or is it already working as needed?
Enter host password for user 'root': { "in_use":false, "persistent":true, "interface":"", "vms":[], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"inactive", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
- this is the generated network XML in libvirt:
[danielhb@arthas kimchi]$ sudo virsh net-dumpxml vepa_net <network> <name>vepa_net</name> <uuid>96da7b58-d655-4fa2-b0f6-d9a026cbf95a</uuid> <forward dev='enp0s25' mode='vepa'> <interface dev='enp0s25'/> </forward> </network>
[danielhb@arthas kimchi]$
2 - In Kimchi UI: - activate the network - create (or edit) a template and add this network to an interface - create a VM using that template.
This is the result interface XML of the VM:
<interface type='network'> <mac address='52:54:00:77:31:30'/> <source network='vepa_net'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
And this is the backend call showing the status of the 'vepa_net' network after these steps:
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/kimchi/networks/vepa_net' Enter host password for user 'root': { "in_use":true, "persistent":true, "interface":"", "vms":[ "vepa-vm" ], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"active", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
Daniel Henrique Barboza (5): VEPA network support: API and i18n changes VEPA network support: xmlutils changes VEPA network support: changes in networks control and model VEPA network support: additional backend unit tests VEPA network support: UI changes
API.json | 2 +- control/networks.py | 5 +++-- docs/API.md | 5 +++++ i18n.py | 5 +++-- model/networks.py | 14 ++++++++++-- tests/test_networkxml.py | 42 +++++++++++++++++++++++++++++++++++- ui/js/src/kimchi.network.js | 9 ++++++-- ui/js/src/kimchi.network_add_main.js | 19 ++++++++++------ ui/pages/network-add.html.tmpl | 5 +++-- xmlutils/network.py | 25 +++++++++++++++++++-- 10 files changed, 111 insertions(+), 20 deletions(-)
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 02/05/2016 05:12 PM, Aline Manera wrote:
On 02/05/2016 04:55 PM, Aline Manera wrote:
On 01/21/2016 11:39 AM, dhbarboza82@gmail.com wrote:
From: Daniel Henrique Barboza <dhbarboza82@gmail.com>
This patch set implements the VEPA network support for Kimchi in the backend and the frontend. VEPA networks are somewhat similar to bridge 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 bridge 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 with an extra parameter called 'vepa_devs', an array of physical devices.
Let me show an example of use:
1- creating the VEPA network (can be done via the UI):
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X POST 'https://localhost:8001/plugins/kimchi/networks' -d'{"name":"vepa_net", "connection":"vepa", "vepa_devs":["enp0s25"]}'
I don't see a reason to do not reuse the 'interface' parameter for this network type.
I understand it can be a list of value for VEPA, but we can change it to "interfaces" and to be a list and ensure only one value is passed for brigded/macvtap network. That way we simplify the API, in terms of getting the same set of parameters to create a network.
Unless the API, the code looks good for me. I only have one more comment: don't we need to change the /interfaces to properly list the VEPA interfaces? Or is it already working as needed?
It was working as intended. A VEPA interface is just a physical interface that is conected to a VEPA switch. No extra code was needed.
Enter host password for user 'root': { "in_use":false, "persistent":true, "interface":"", "vms":[], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"inactive", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
- this is the generated network XML in libvirt:
[danielhb@arthas kimchi]$ sudo virsh net-dumpxml vepa_net <network> <name>vepa_net</name> <uuid>96da7b58-d655-4fa2-b0f6-d9a026cbf95a</uuid> <forward dev='enp0s25' mode='vepa'> <interface dev='enp0s25'/> </forward> </network>
[danielhb@arthas kimchi]$
2 - In Kimchi UI: - activate the network - create (or edit) a template and add this network to an interface - create a VM using that template.
This is the result interface XML of the VM:
<interface type='network'> <mac address='52:54:00:77:31:30'/> <source network='vepa_net'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
And this is the backend call showing the status of the 'vepa_net' network after these steps:
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/kimchi/networks/vepa_net' Enter host password for user 'root': { "in_use":true, "persistent":true, "interface":"", "vms":[ "vepa-vm" ], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"active", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
Daniel Henrique Barboza (5): VEPA network support: API and i18n changes VEPA network support: xmlutils changes VEPA network support: changes in networks control and model VEPA network support: additional backend unit tests VEPA network support: UI changes
API.json | 2 +- control/networks.py | 5 +++-- docs/API.md | 5 +++++ i18n.py | 5 +++-- model/networks.py | 14 ++++++++++-- tests/test_networkxml.py | 42 +++++++++++++++++++++++++++++++++++- ui/js/src/kimchi.network.js | 9 ++++++-- ui/js/src/kimchi.network_add_main.js | 19 ++++++++++------ ui/pages/network-add.html.tmpl | 5 +++-- xmlutils/network.py | 25 +++++++++++++++++++-- 10 files changed, 111 insertions(+), 20 deletions(-)
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 02/05/2016 04:55 PM, Aline Manera wrote:
On 01/21/2016 11:39 AM, dhbarboza82@gmail.com wrote:
From: Daniel Henrique Barboza <dhbarboza82@gmail.com>
This patch set implements the VEPA network support for Kimchi in the backend and the frontend. VEPA networks are somewhat similar to bridge 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 bridge 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 with an extra parameter called 'vepa_devs', an array of physical devices.
Let me show an example of use:
1- creating the VEPA network (can be done via the UI):
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X POST 'https://localhost:8001/plugins/kimchi/networks' -d'{"name":"vepa_net", "connection":"vepa", "vepa_devs":["enp0s25"]}'
I don't see a reason to do not reuse the 'interface' parameter for this network type.
Because it would change the meaning of the 'interface' parameter to all APIs. It would go from a single interface to an array of interfaces.
I understand it can be a list of value for VEPA, but we can change it to "interfaces" and to be a list and ensure only one value is passed for brigded/macvtap network. That way we simplify the API, in terms of getting the same set of parameters to create a network.
In my opinion change 'interface' to 'interfaces' is creating a whole new parameter instead of reusing the existing one :P but I understand your point. It will take some time adjusting all the existing UI calls and backend unit tests to interpret this new 'interfaces' parameter, but I'll do it.
Enter host password for user 'root': { "in_use":false, "persistent":true, "interface":"", "vms":[], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"inactive", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
- this is the generated network XML in libvirt:
[danielhb@arthas kimchi]$ sudo virsh net-dumpxml vepa_net <network> <name>vepa_net</name> <uuid>96da7b58-d655-4fa2-b0f6-d9a026cbf95a</uuid> <forward dev='enp0s25' mode='vepa'> <interface dev='enp0s25'/> </forward> </network>
[danielhb@arthas kimchi]$
2 - In Kimchi UI: - activate the network - create (or edit) a template and add this network to an interface - create a VM using that template.
This is the result interface XML of the VM:
<interface type='network'> <mac address='52:54:00:77:31:30'/> <source network='vepa_net'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
And this is the backend call showing the status of the 'vepa_net' network after these steps:
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/kimchi/networks/vepa_net' Enter host password for user 'root': { "in_use":true, "persistent":true, "interface":"", "vms":[ "vepa-vm" ], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"active", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
Daniel Henrique Barboza (5): VEPA network support: API and i18n changes VEPA network support: xmlutils changes VEPA network support: changes in networks control and model VEPA network support: additional backend unit tests VEPA network support: UI changes
API.json | 2 +- control/networks.py | 5 +++-- docs/API.md | 5 +++++ i18n.py | 5 +++-- model/networks.py | 14 ++++++++++-- tests/test_networkxml.py | 42 +++++++++++++++++++++++++++++++++++- ui/js/src/kimchi.network.js | 9 ++++++-- ui/js/src/kimchi.network_add_main.js | 19 ++++++++++------ ui/pages/network-add.html.tmpl | 5 +++-- xmlutils/network.py | 25 +++++++++++++++++++-- 10 files changed, 111 insertions(+), 20 deletions(-)
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 02/05/2016 05:17 PM, Daniel Henrique Barboza wrote:
On 02/05/2016 04:55 PM, Aline Manera wrote:
On 01/21/2016 11:39 AM, dhbarboza82@gmail.com wrote:
From: Daniel Henrique Barboza <dhbarboza82@gmail.com>
This patch set implements the VEPA network support for Kimchi in the backend and the frontend. VEPA networks are somewhat similar to bridge 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 bridge 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 with an extra parameter called 'vepa_devs', an array of physical devices.
Let me show an example of use:
1- creating the VEPA network (can be done via the UI):
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X POST 'https://localhost:8001/plugins/kimchi/networks' -d'{"name":"vepa_net", "connection":"vepa", "vepa_devs":["enp0s25"]}'
I don't see a reason to do not reuse the 'interface' parameter for this network type.
Because it would change the meaning of the 'interface' parameter to all APIs. It would go from a single interface to an array of interfaces.
I understand it can be a list of value for VEPA, but we can change it to "interfaces" and to be a list and ensure only one value is passed for brigded/macvtap network. That way we simplify the API, in terms of getting the same set of parameters to create a network.
In my opinion change 'interface' to 'interfaces' is creating a whole new parameter instead of reusing the existing one :P but I understand your point.
It will take some time adjusting all the existing UI calls and backend unit tests to interpret this new 'interfaces' parameter, but I'll do it.
Thanks! ;-)
Enter host password for user 'root': { "in_use":false, "persistent":true, "interface":"", "vms":[], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"inactive", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
- this is the generated network XML in libvirt:
[danielhb@arthas kimchi]$ sudo virsh net-dumpxml vepa_net <network> <name>vepa_net</name> <uuid>96da7b58-d655-4fa2-b0f6-d9a026cbf95a</uuid> <forward dev='enp0s25' mode='vepa'> <interface dev='enp0s25'/> </forward> </network>
[danielhb@arthas kimchi]$
2 - In Kimchi UI: - activate the network - create (or edit) a template and add this network to an interface - create a VM using that template.
This is the result interface XML of the VM:
<interface type='network'> <mac address='52:54:00:77:31:30'/> <source network='vepa_net'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
And this is the backend call showing the status of the 'vepa_net' network after these steps:
[danielhb@arthas kimchi]$ curl -k -u root -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/kimchi/networks/vepa_net' Enter host password for user 'root': { "in_use":true, "persistent":true, "interface":"", "vms":[ "vepa-vm" ], "subnet":"", "vepa_devs":[ "enp0s25" ], "name":"vepa_net", "state":"active", "connection":"vepa", "autostart":true, "dhcp":{ "start":"", "end":"" } }[danielhb@arthas kimchi]$
Daniel Henrique Barboza (5): VEPA network support: API and i18n changes VEPA network support: xmlutils changes VEPA network support: changes in networks control and model VEPA network support: additional backend unit tests VEPA network support: UI changes
API.json | 2 +- control/networks.py | 5 +++-- docs/API.md | 5 +++++ i18n.py | 5 +++-- model/networks.py | 14 ++++++++++-- tests/test_networkxml.py | 42 +++++++++++++++++++++++++++++++++++- ui/js/src/kimchi.network.js | 9 ++++++-- ui/js/src/kimchi.network_add_main.js | 19 ++++++++++------ ui/pages/network-add.html.tmpl | 5 +++-- xmlutils/network.py | 25 +++++++++++++++++++-- 10 files changed, 111 insertions(+), 20 deletions(-)
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (6)
-
Aline Manera -
Daniel Henrique Barboza -
Daniel Henrique Barboza -
dhbarboza82＠gmail.com
-
Lucio Correia -
Paulo Vital