Hello everybody,
On 07/25/2013 02:47 PM, Guido Trotter wrote:
On Thu, Jul 25, 2013 at 1:43 PM, Sebastian Gebhard <[email protected]> wrote:
Hi there,
[resend again, as it didn't arrive on the list]
yesterday I gave the OpenvSwitch implementation for KVM some thoughts.
Especially the vlan stuff. I came across Dimitris NIC refactoring [1] which
introduces common functions for KVM and XEN networking using
tools/net-common.in for common functionality which is used by
tools/kvm-ifup.in and tools/vif-ganeti.in respectively.
I think this approach is very good, because it keeps networking as
hypervisor indepentend as it can. Now my implementation of vlan uses
vif-openvswitch which comes with XEN 4.3 and is not compatible with
vif-ganeti right now.
vif-openvswitch requires bridge=switch1.onevlan:anothervlan
whereas
vif-ganeti requires bridge=switch1 (which will crash when giving it
switch1.2:3:4 or something)
I would suggest to merge the functionality of vif-openvswitch into
vif-ganeti. This way users stay independent of whether they wanna use
vif-ganeti or vif-openvswitch.
+1. Not only, but also in net-common, so it can be used under kvm as well.
+1! That's exactly what we were discussing internally with Dimitris
this week and were ready to propose. Specifically, I'd propose a
workflow like the following:
If hypervisor=kvm:
run kvm-ifup:
Inside kvm-ifup:
if custom script (kvm-vif-bridge) is found run that
else
run default actions
If hypervisor=xen:
run vif-ganeti
Inside vif-ganeti:
if custom script (vif-custom) is found run that
else
run default actions
In the second workflow the 'default actions' will
include running the actual vif-openvswitch script,
if mode=openvswitch
Anyway, I think this is a good direction and keeps the hypervisor
abstraction. I'm sure Dimitris would like to comment too, since
he knows the exact details.
Just a note here. I think we should probably rename
those scripts at some point, so that they have more
consistent naming. One quick suggestion would be:
kvm-ifup -> kvm-vif-ganeti
kvm-vif-bridge -> kvm-vif-custom
vif-ganeti -> xen-vif-ganeti
vif-custom -> xen-vif-custom
net-common -> vif-common
Thanks,
Constantinos
What are your thoughts about that? Do you see any issues I may have
overseen?
Also, I would base my future implementations (QoS for example) on this
structure.
Indeed, it would be good if the implementation was independent of
vif-openvswitch vs vif-ganeti, and of course compatible with all the
ganeti hypervisors, and not dependent on Xen.
Thanks,
Guido