[Users] libteam network devices support in ovirt

[Antoni Segura Puimedon]

----- Original Message -----
> From: "Tomasz Torcz" <tomek at pipebreaker.pl>
> To: "Antoni Segura Puimedon" <asegurap at redhat.com>
> Cc: users at ovirt.org
> Sent: Friday, November 1, 2013 11:09:01 AM
> Subject: Re: [Users] libteam network devices support in ovirt
> 
> On Wed, Oct 30, 2013 at 07:50:50PM -0400, Antoni Segura Puimedon wrote:
> > ----- Original Message -----
> > > From: "Tomasz Torcz" <tomek at pipebreaker.pl>
> > > To: "Antoni Segura Puimedon" <asegurap at redhat.com>
> > > Cc: users at ovirt.org
> > > Sent: Wednesday, October 30, 2013 5:19:04 PM
> > > Subject: Re: [Users] libteam network devices support in ovirt
> > > 
> > > On Wed, Oct 30, 2013 at 03:34:03PM +0100, Antoni Segura Puimedon wrote:
> > > > On Wed, 2013-10-30 at 11:24 +0100, Tomasz Torcz wrote:
> > > > > Hi,
> > > > > 
> > > > >   Little over a year ago Fedora introduced alternative bonding driver
> > > > > for network devices - libteam: https://fedorahosted.org/libteam/
> > > > >   Can we expect libteam support in ovirt at the same level as for
> > > > >   "bond"
> > > > > driver?  Currently, libteam bonded interfaces are not visible in
> > > > > "Setup Host Networks" dialog.
> > > > 
> > > > Hi Tomasz,
> > > > 
> > > > We are aware of libteam bonds and I personally look forward to them
> > > > very
> > > > much.
> > > > 
> > > > The ideal way to support them would be via one new network configurator
> > > > that
> > > > would implicitly make teamd bonds instead of usual bonds. After the
> > > > iproute2
> > > > configurator is finished (it is currently in progress but quite
> > > > functional)
> > > > it
> > > > should be quite easy to inherit from vdsm/netconf/iproute2.py and
> > > > modify
> > > > configureBond, removeBond and editBondings so that they make use of
> > > > teamd
> > > > bonds.
> > > 
> > >   What needs to be done to get ”minimal” support?  By minimal I
> > >   understand
> > > oVirt acknowledging that network interfaces are teamed.  Configuring
> > > teams
> > > from oVirt can come later.  Right now teamed interfaces are displayed
> > > as separate in net configuration dialog, and master team device is not
> > > displayed at all.  I could live with manually configure teams if only
> > > I can attach them to ovirt networks.
> > 
> > would that be a bridged or a bridgeless network? A vlanned or non-vlanned
> > network?
> 
>   I'm not entirely sure if you honestly asking or just trying to make me
> realize how many variables are involved in such support.  I will assume the
> former.

I was asking because if it were non-VM network it could have been easy to put
up a hack to do it.

> 
>   I have team0 interface of two physical NICs.  I'd like to have this team0
> interface attached to particular VM.  That would mean bridged network I
> suppose.

Hacking around attempts (not actually tried)
=============================================

Well, I guess that what you could do is to configure the whole network manually
create the bridge and add team0 to it manually, then craft the ifcfg files for
them. Then create the libvirt xml definition for the network over the bridge.
After that maybe the engine will pick up the network as defined in the host and
let you start VMs with it.

Another thing that might (just might) work would be to use the engine to set up
a vm network overt a normal bond and then just use brctl to replace bond0 for
team0 on that bridge. This would save you from the libvirt network definition
(you should remove the bond from the bridge in ifcfg files as well).

However, in both options, you might have the issue of the engine detecting the
configuration as out of sync.

> There are no VLANs in my setup.
>   To be clear, I am able to tear down this setup and revert to old-school
>   bond.
> I'd prefer not to – it needs some downtime to reconfigure and validate.
> So now I'm against the question: what will require more work from me,
> reconfiguring network or making ovirt recognize basic team0.
> 
> 
> --
> Tomasz Torcz                 Morality must always be based on practicality.
> xmpp: zdzichubg at chrome.pl                -- Baron Vladimir Harkonnen
> 
> 

In the end, the best thing would be to request a feature for team support. It would
entail making netinfo able to report team devices as bonds and inheriting from some
configurator (it could be done entirely on vdsm side).