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> > _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel