[libvirt] [Team2013] Integrating LiSA into libvirt

[Laine Stump]

On 09/16/2013 06:32 AM, Radu Rendec wrote:
> On Mon, 2013-09-16 at 11:02 +0100, Daniel P. Berrange wrote:
>> Looking at the website it seems that it requires custom kernel
>> branches, and the most recent kernel branch I see, with patches
>> from last 2 months, is based on the pretty old 2.6.32 release ?
>> The website also indicates the kernel<->userspace API is not
>> ABI stable.
> Unfortunately, our website is not up-to-date with the latest development
> effort that has been put into the source code.
>
> We've recently changed LiSA to be switching engine agnostic. Now it can
> work with the "bridge" and "8021q" modules, which are part of the stock
> linux kernel.

1) What are the advantages of using LiSA vs. using the standard Linux
host bridge without LiSA? vs. openvswitch?

2) Since LiSA can use the standard Linux host bridge, is it possible to
use the LiSA userspace utilities on a bridge that was created in the
traditional manner (i.e. one of the bridge's that libvirt creates
today)? This may actually provide all the functionality that you're
looking for.

(I can imagine though that, for example, if LiSA is able to support
per-port vlan configuration, it might be nice to be able to translate
that information from the interface (or network or portgroup) config
into the proper LiSA command/ioctl/whatever to setup the vlan tag for a
port.)

3) Since LiSA is apparently using standard tap devices for all its
connections, if libvirt did add any sort of support for it, I think it
should be in a form parallel to the openvswitch/802.1Qb[gh] support,
which continues to use <interface type='bridge'> (or <interface
type='network'>) with switching technology-specific details in the
<virtualport type='<openvswitch|8021Qbg|8021Qbh)'> sub-element of the
<interface> or <network>.


>
> Our custom kernel module is "yet another engine" that LiSA supports, but
> it's not a requirement.
>
>> I must say I don't know all that much about networking. My main
>> uninformed question would be how does this LiSA kernel support
>> differ from/relate to OpenVSwitch which seems to be the technology
>> the kernel community has decided upon for next generation network
>> capabilities in Linux. I'm rather loathe consider support for new
>> Linux networking features based on out-of-tree kernel patches.
> I completely understand your point, but maybe you'll reconsider now that
> you know an out-of-tree patch is not actually required.

Purely from the point of view of "let's see if we've abstracted the
networking well enough to cleanly support a new technology" this would
be interesting. But I am in agreement with Dan that we need to be sure
that it is something that is "standards track", has good momentum, has a
stable ABI, and offers a definite gain in functionality and/or user-base
prior to committing to supporting it in libvirt - once something goes
into the libvirt API, we guarantee that it will continue to be supported
effectively "forever", so we can't make the decision too lightly.


>
> As for our out-of-tree module, we actually tried to push it upstream a
> couple of years ago, but the kernel networking team said that it didn't
> make sense to add a new module with similar functionality to already
> existing modules and that we should have fixed those instead (if
> something had been wrong with them).
>
> That was even before OpenVSwitch was released as open source. I'm
> actually disappointed about this. LiSA was out in 2005 - that's 4 years
> before OpenVSwitch, but nobody cared.

Yes, unfortunately marketing is very often just as important as (or even
more important than) the quality of the code.