[vdsm] Future of Vdsm network configuration

Simon Grinberg simon at redhat.com
Tue Nov 13 09:11:59 UTC 2012



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: vdsm-devel at fedorahosted.org, "Mark Wu" <wudxw at linux.vnet.ibm.com>
> Sent: Tuesday, November 13, 2012 10:13:41 AM
> Subject: Re: [vdsm] Future of Vdsm network configuration
> 
> 
> 
> ----- Original Message -----
> > From: "Simon Grinberg" <simon at redhat.com>
> > To: "Mark Wu" <wudxw at linux.vnet.ibm.com>
> > Cc: vdsm-devel at fedorahosted.org, "Alon Bar-Lev" <alonbl at redhat.com>
> > Sent: Tuesday, November 13, 2012 10:06:42 AM
> > Subject: Re: [vdsm] Future of Vdsm network configuration
> > 
> > 
> > > > Hypervisor should be a total slave of manager (or cluster), so
> > > > I
> > > > have
> > > > no problem in bypassing/disabling any distribution specific
> > > > tool
> > > > in
> > > > favour of atoms (brctl, iproute), in non persistence mode.
> > 
> > 
> > > Do you mean just using the utilities (brctl, iproute) on demand
> > > and
> > > not
> > > keeping any network configuration
> > > on vdsm host? Then manager needs reconfigure network on every
> > > host
> > > reboot. Actually, I like this way.
> > > It could be more flexible than libvirt's virInterface (netcf or
> > > NM)
> > > and have fine-grained control to handle some tough cases.
> > > Moreover,
> > > it's clean than the current mangling network configuration files.
> > 
> > +1,
> > I've raised that is the past, I don't think the network
> > configuration
> > done by the engine should be persisted. This way the admin sets up
> > the node in a persistent way such that it always succeeds to boot
> > and has a rout to the engine. Engine on node activation updates the
> > network, connects to storage etc.
> > 
> > Now that setupNetworks can do it in one atomic operation this is
> > the
> > way to go, very simple.
> > It's also eases the move of a node from a cluster to cluster. With
> > current concept, after you move the host you need to modify the
> > node
> > networks to fit the new cluster topology. With non-persistent,
> > placing a host into maintenance should also revert the host to the
> > original networking after boot same as it disconnects the storage.
> > Now you can easily move the node from cluster to cluster or even a
> > differed DC. As soon as you activate - it is configured with the
> > new
> > DC/Cluster pair requirements.
> > 
> > And it's a valuable step in the direction of -> Go go dynamic host
> > allocation :)
> > 
> 
> So I am not the only insane one where!
> Good to know!

Hold your horses, all I've said is that I strongly agree that networks should be dynamically set from the engine, I did not comment on how. 

If there is a cross distribution utility out there that can do this in <bold> reliable <\bold> manner and actually <bold> offloads <\bold> logic from VDSM, meaning it's simpler then direct usage of mkdev, ip, brctl, etc to configure the hosts networking, it should be considered. 

What's important is the goal and not the way there. 
One of my goals, is returning to the stateless node concept the ovirt node had started with so many, many years (5?) ago. It just makes sense.

BTU,
I've always been insane, they just didn't caught up with me yet.  

> 
> Alon
> 


More information about the vdsm-devel mailing list