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

Reply via email to