> ----- Original Message -----
> > From: "Itamar Heim" <ih...@redhat.com>
> > To: "Roni Luxenberg" <rluxe...@redhat.com>
> > Cc: "Alon Bar-Lev" <alo...@redhat.com>, "VDSM Project Development"
> > <vdsm-devel@lists.fedorahosted.org>
> > Sent: Wednesday, November 28, 2012 2:01:45 PM
> > Subject: Re: [vdsm] Future of Vdsm network configuration - Thread
> > mid-summary
> > 
> > On 11/28/2012 05:34 AM, Roni Luxenberg wrote:
> > >> ----- Original Message -----
> > >>> From: "Itamar Heim" <ih...@redhat.com>
> > >>> To: "Dan Kenigsberg" <dan...@redhat.com>
> > >>> Cc: "Alon Bar-Lev" <alo...@redhat.com>, "VDSM Project
> > >>> Development"
> > >>> <vdsm-devel@lists.fedorahosted.org>, "Yaniv Kaul"
> > >>> <yk...@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?
> > >>>
> > >>
> > > all bond modes have to cope with a situation where only a single
> > > nic is active and the rest are down,
> > > so one can boot with a single active nic and only activate the
> > > rest
> > > and promote to the desired bond mode upon getting the full
> > > network
> > > configuration from the manager.
> > 
> > of course they need to handle single active nic, but iirc, the host
> > must
> > be configured for a matching bond as the switch.
> > i.e., you can't configure the switch to be in bond, then boot the
> > host
> > with a "single active nic" in a non bonded config
> 
> as far as I know as long as the 2nd nic is down there is no problem.
> it is as if the cord is out.
> 
regular port grouping or trunking on adjacent switch does not mandate bond 
configuration on the host as long as only a single nic is active. OTAH, 802.3ad 
port grouping might require host configuration as link aggregation control 
packets are exchanged on the wire. If this is the case, you'd need to persist 
your L2 bonding config.

> > 
> > >
> > >> 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.
> > >>
> > > you mainly need OVS for provisioning VM networks so here too you
> > > can completely bypass OVS during boot and only configure it in a
> > > transactional manner upon getting the full network configuration
> > > from the manager.
> > >
> > > a general question, why would you need to configure VM networks
> > > on
> > > the host (assuming a persistent cached configuration) upon boot
> > > if
> > > it cannot talk to the manager?
> > > after-all, in this case no resources would be scheduled to run on
> > > this host until connection to the manager is restored and
> > > up-to-date network configuration is applied.
> > >
> > > thanks,
> > > Roni
> > >
> > 
> > 
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to