[Kimchi-devel] RFC: Templates API changes for 'networks' attribute

[Aline Manera]

Hi all,

Such a big discussion but I think I got the idea.

My proposal would follow the same approach I suggested for the storage 
pool issue.
As we are close to the code freeze for 2.3 release I will recommend to 
change as less as possible the current design.

Said that, I will say to have a different template.conf file for s390x 
system on which we will have the 'dirpath' instead of the 'pool' 
information and the 'interfaces' section instead of the 'networks' 
parameter.

Exactly what Chandra has proposed:

[interfaces]

[interfaces.1]
#type=macvtap
#name=eth0, eth1
#mode=bridge or vepa

Note that behavior/config will be only allowed for s390x system. For ppc 
and x86, we continue to use 'networks' and 'pool' information.
My idea here is to support s390x according to its libvirt limitation 
without change the current design for ppc and x86.

That way, we will need to change the templates API to insert a new and 
optional parameter 'interfaces' that will be valid only for s390x system.

To add a new network to a guest (/vms/*name*/ifaces), I recommend to add 
2 new and optional parameters: mode and source.
And keep 'network' parameter for ppc and x86.

So we would have:

* model (optional): model of emulated network interface card. It can be 
one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, 
e1000, pcnet and virtio. When model is missing, libvirt will set 
'rtl8139' as default value.
* network: *Only for ppc and x86 systems*. Network name
* source: *Only valid for s390x system*. Interface or resource bridge name
* type: For s390x systems, the supported types are 'network', ‘macvtap’ 
| ‘ovs’ type. For ppc and x86, only 'network' is supported.
* mode: *Only valid for s390x system*. Supported values ’bridge’ or 
‘vepa’. required only if type=‘macvtap’

What do you think about it?

Once we get it established we can open the support for ppc and x86.

Regards,
Aline Manera

On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
> Hi All,
> To support, attaching a physical interface to guest as macvtap or 
> attaching ovs bridge to guest without creating libvirt network, I 
> propose following changes to 'networks' attribute of templates josn.
>
> current implementation:
> 'networks' attribute expects list of virtual network names
>
> changes:
> 'networks': list of dictionary
>                 type: can be direct, network or bridge
>                 interface: name of physical interface(type=direct) or 
> ovs (type=bridge) or virtual network(type=direct)
>                 mode(required if type=direct): bridge or vepa
>
> for macvtap: type is direct and mode can be bridge or vepa
> for ovs: type is bridge and mode is not required
> for virtual network: type=network(current implementation)
>
> Examples of network xml for attaching macvtap and ovs to guest without 
> libvirt:
> OVS:
> <interface type="bridge">
>   <source bridge="vswitch0"/>
>   <virtualport type="openvswitch"/>
>   <model type="virtio"/>
> </interface>
>
> macvtap with bridge mode:
> <interface type="direct">
>   <source dev="eth0" mode="bridge"/>
>   <model type="virtio"/>
> </interface>
>
>  macvtap with vepa mode:
> <interface type="direct">
>   <source dev="bond0" mode="vepa"/>
>   <model type="virtio"/>
> </interface>
>