[vdsm] Future of Vdsm network configuration - Thread mid-summary

Alon Bar-Lev alonbl at redhat.com
Wed Nov 28 09:12:49 UTC 2012



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "Yaniv Kaul"
> <ykaul at redhat.com>
> Sent: Wednesday, November 28, 2012 11:01:35 AM
> Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
> 
> On 11/28/2012 03:53 AM, Dan Kenigsberg wrote:
> > On Tue, Nov 27, 2012 at 03:24:58PM -0500, Alon Bar-Lev wrote:
> >>
> >>
> >
> >>>>
> >>>> Management interface configuration is a separate issue.
> >
> > But it is an important issue that has to be discussed..
> >
> >>>> If we perform changes of this interface when host is in
> >>>> maintenance
> >>>> we reduce the complexity of the problem.
> >>>>
> >>>> For your specific issue, if there are two interfaces, one which
> >>>> is
> >>>> up during boot and one which is down during boot, there is no
> >>>> problem to bond them after boot without persisting
> >>>> configuration.
> >>>
> >>> how would you know which bond mode to use? which MTU?
> >>
> >> I don't understand the question.
> >
> > I think I do: Alon suggests that on boot, the management interface
> > would
> > not have bonding at all, and use a single nic. The switch would
> > have to
> > assume that other nics in the bond are dead, and will use the only
> > one
> > which is alive to transfer packets.
> >
> > There is no doubt that we have to persist the vlan tag of the
> > management
> > interface, and its MTU, in the extremely rare case where the
> > network
> > would not alow Linux's default of 1500.
> 
> i was thinking manager may be using jumbo frames to talk to host, and
> host will have an issue with them since it is set to 1500 instead of
> 8k.
> jumbo frames isn't a rare case.
> 
> as for bond, are you sure you can use a nic in a non bonded mode for
> all
> bond modes?
> 

Changing the master interface mtu for either vlan or bond is required for management interface and non management interface.

So the logic would probably be set max(mtu(slaves)) regardless it is management interface or not.

I discussed this with Livnat, if there are applications that access the master interface directly we may break them, as the destination may not support non standard mtu.

This is true in current implementation and any future implementation.

It is bad practice to use the master interface directly (mixed tagged/untagged), better to define in switch that untagged communication belongs to vlanX, then use this explicit vlanX at host.

> next, what if we're using openvswitch, and you need some flow
> definitions for the management interface?

I cannot answer that as I don't know openvswitch very well and don't know what "flow definitions" are, however, I do guess that it has non persistent mode that can effect any interface on its control. If you like I can research this one.

Alon


More information about the vdsm-devel mailing list