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

[Aline Manera]

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 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.
>

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 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
>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>