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

> 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