Re: [Kimchi-devel] RFC: Templates API changes for 'networks' attribute
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>