----- 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.

> 
> >
> >> 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