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

Daniel Henrique Barboza dhbarboza82 at gmail.com
Tue Aug 9 18:54:15 UTC 2016


I am worried not only by the API.json changes but also in the
potential backend changes required. Do you have any prediction of
how far these changes might go?

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




More information about the Kimchi-devel mailing list