[vdsm] Future of Vdsm network configuration

Alon Bar-Lev alonbl at redhat.com
Tue Nov 13 08:13:41 UTC 2012



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

Alon


More information about the vdsm-devel mailing list