[Kimchi-devel] [PATCH] [Kimchi 0/5] VEPA network support
Daniel Henrique Barboza
dhbarboza82 at gmail.com
Fri Feb 5 19:19:38 UTC 2016
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 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.
>>
>> 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 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
>>
>
More information about the Kimchi-devel
mailing list