[Kimchi-devel] [PATCH] [Kimchi 0/5] VEPA network support

[Daniel Henrique Barboza]

On 02/05/2016 04:55 PM, Aline Manera wrote:
>
>
> On 01/21/2016 11:39 AM, dhbarboza82 at gmail.com wrote:
>> From: Daniel Henrique Barboza <dhbarboza82 at 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 at 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 at arthas kimchi]$
>>
>> - this is the generated network XML in libvirt:
>>
>>
>> [danielhb at 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 at 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 at 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 at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>