----- Original Message -----
> From: "Alon Bar-Lev" <alo...@redhat.com>
> To: "Dan Kenigsberg" <dan...@redhat.com>
> Cc: vdsm-de...@fedorahosted.org
> Sent: Sunday, November 11, 2012 3:46:43 PM
> Subject: Re: [vdsm] Future of Vdsm network configuration
>
>
>
> ----- Original Message -----
> > From: "Dan Kenigsberg" <dan...@redhat.com>
> > To: vdsm-de...@fedorahosted.org
> > Sent: Sunday, November 11, 2012 4:07:30 PM
> > Subject: [vdsm] Future of Vdsm network configuration
> >
> > Hi,
> >
> > Nowadays, when vdsm receives the setupNetowrk verb, it mangles
> > /etc/sysconfig/network-scripts/ifcfg-* files and restarts the
> > network
> > service, so they are read by the responsible SysV service.
> >
> > This is very much Fedora-oriented, and not up with the new themes
> > in Linux network configuration. Since we want oVirt and Vdsm to be
> > distribution agnostic, and support new features, we have to change.
> >
> > setupNetwork is responsible for two different things:
> > (1) configure the host networking interfaces, and
> > (2) create virtual networks for guests and connect the to the world
> > over (1).
> >
> > Functionality (2) is provided by building Linux software bridges,
> > and
> > vlan devices. I'd like to explore moving it to Open vSwitch, which
> > would
> > enable a host of functionalities that we currently lack (e.g.
> > tunneling). One thing that worries me is the need to reimplement
> > our
> > config snapshot/recovery on ovs's database.
> >
> > As far as I know, ovs is unable to maintain host level parameters
> > of
> > interfaces (e.g. eth0's IPv4 address), so we need another
> > tool for functionality (1): either speak to NetworkManager
> > directly,
> > or
> > to use NetCF, via its libvirt virInterface* wrapper.
> >
> > I have minor worries about NetCF's breadth of testing and usage; I
> > know
> > it is intended to be cross-platform, but unlike ovs, I am not aware
> > of a
> > wide Debian usage thereof. On the other hand, its API is ready for
> > vdsm's
> > usage for quite a while.
> >
> > NetworkManager has become ubiquitous, and we'd better integrate
> > with
> > it
> > better than our current setting of NM_CONTROLLED=no. But as DPB
> > tells
> > us,
> > https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-November/001677.html
> > we'd better offload integration with NM to libvirt.
> >
> > We would like to take Network configuration in VDSM to the next
> > level
> > and make it distribution agnostic in addition for setting the
> > infrastructure for more advanced features to be used going forward.
> > The path we think of taking is to integrate with OVS and for
> > feature
> > completeness use NetCF, via its libvirt virInterface* wrapper. Any
> > comments or feedback on this proposal is welcomed.
> >
> > Thanks to the oVirt net team members who's input has helped writing
> > this
> > email.
>
> Hi,
>
> As far as I see this, network manager is a monster that is a huge
> dependency to have just to create bridges or configure network
> interfaces... It is true that on a host where network manager lives
> it would be not polite to define network resources not via its
> interface, however I don't like we force network manager.
>
> libvirt is long not used as virtualization library but system
> management agent, I am not sure this is the best system agent I
> would have chosen.
>
> I think that all the terms and building blocks got lost in time...
> and the result integration became more and more complex.
>
> Stabilizing such multi-layered component environment is much harder
> than monolithic environment.
>
> I would really want to see vdsm as monolithic component with full
> control over its resources, I believe this is the only way vdsm can
> be stable enough to be production grade.
>
> 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.
So you propose that we would keep the network configuration database
ourselves (something like sqlite maybe), disable network.service and
networkmanager.service and put up and down the interfaces we need via
brctl/iproute, sysfs and other netlink talking interfaces right?
I won't deny that for hypervisor nodes it sounds really well. For
installations on machines that maybe serve other purposes as well, it
could be slightly problematic. Not the part of managing the network,
but the part of disabling network manager and network.service.
Since what you said was bypass NM and network.service, maybe it would
be better instead to leave whichever is default enabled and let
the user define which interfaces we should manage, and make those
unavailable to NM and network.service. Thre are four cases here:
NM enabled network.service disabled:
Simply create ifcfg-* for the interfaces that we want to manage
that include NM_CONTROLLED=no and the MAC address of the interface.
NM disabled and network.service disabled:
Just make sure that the interfaces we are to manage do not have
a ifcfg-* file.
NM disabled and network.service disabled:
No special requirements to make it work.
NM enabled and network.service enabled:
Make sure that there are no ifcfg-* files for the interfaces we
manage and create a NM keyfile stating the interface as not
managed.
Alon, just correct me if I am wrong in my interpretation of what you
said, I wanted to expand on it to make sure I understood it well.
Best, Toni
>
> I know this derive some more work, but I don't think it is that
> complex to implement and maintain.
>
> Just my 2 cents...
>
> Regards,
> Alon
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
