9:48 p.m.
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>