7:39 a.m.
From: Daniel Henrique Barboza <dhbarboza82(a)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
7:39 a.m.
New subject: [PATCH] [Kimchi 1/5] VEPA network support: API and i18n changes
From: Daniel Henrique Barboza <dhbarboza82(a)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(a)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
7:39 a.m.
New subject: [PATCH] [Kimchi 2/5] VEPA network support: xmlutils changes
From: Daniel Henrique Barboza <dhbarboza82(a)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(a)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
7:39 a.m.
New subject: [PATCH] [Kimchi 3/5] VEPA network support: changes in networks control and model
From: Daniel Henrique Barboza <dhbarboza82(a)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(a)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
7:39 a.m.
New subject: [PATCH] [Kimchi 4/5] VEPA network support: additional backend unit tests
From: Daniel Henrique Barboza <dhbarboza82(a)gmail.com>
Added extra tests to assert the resulting VEPA network
XML.
Signed-off-by: Daniel Henrique Barboza <dhbarboza82(a)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
7:39 a.m.
New subject: [PATCH] [Kimchi 5/5] VEPA network support: UI changes
From: Daniel Henrique Barboza <dhbarboza82(a)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(a)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
10:53 a.m.
Reviewed-by: Paulo Vital <pvital(a)linux.vnet.ibm.com>
On 01/21/2016 11:39 AM, dhbarboza82(a)gmail.com wrote:
From: Daniel Henrique Barboza <dhbarboza82(a)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(-)
12:30 p.m.
Reviewed-By: Lucio Correia <luciojhc(a)linux.vnet.ibm.com>
On 21-01-2016 11:39, dhbarboza82(a)gmail.com wrote:
From: Daniel Henrique Barboza <dhbarboza82(a)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
12:55 p.m.
On 01/21/2016 11:39 AM, dhbarboza82(a)gmail.com wrote:
From: Daniel Henrique Barboza <dhbarboza82(a)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(-)
1:12 p.m.
On 02/05/2016 04:55 PM, Aline Manera wrote:
On 01/21/2016 11:39 AM, dhbarboza82(a)gmail.com wrote:
> From: Daniel Henrique Barboza <dhbarboza82(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
1:17 p.m.
On 02/05/2016 04:55 PM, Aline Manera wrote:
On 01/21/2016 11:39 AM, dhbarboza82(a)gmail.com wrote:
> From: Daniel Henrique Barboza <dhbarboza82(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
1:19 p.m.
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(a)gmail.com wrote:
>> From: Daniel Henrique Barboza <dhbarboza82(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
1:30 p.m.
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(a)gmail.com wrote:
>> From: Daniel Henrique Barboza <dhbarboza82(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
3000
days inactive
3015
days old
12 comments
6 participants
participants (6)
-
Aline Manera -
Daniel Henrique Barboza -
Daniel Henrique Barboza -
dhbarboza82＠gmail.com
-
Lucio Correia -
Paulo Vital