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>