[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