<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 11/11/2012 10:46 PM, Alon Bar-Lev
      wrote:<br>
    </div>
    <blockquote
      cite="mid:1116612527.8262080.1352645203913.JavaMail.root@redhat.com"
      type="cite">
      <pre wrap="">

----- Original Message -----
</pre>
      <blockquote type="cite">
        <pre wrap="">From: "Dan Kenigsberg" <a class="moz-txt-link-rfc2396E" href="mailto:danken@redhat.com">&lt;danken@redhat.com&gt;</a>
To: <a class="moz-txt-link-abbreviated" href="mailto:vdsm-devel@fedorahosted.org">vdsm-devel@fedorahosted.org</a>
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,
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-November/001677.html">https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-November/001677.html</a>
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.
</pre>
      </blockquote>
      <pre wrap="">
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.</pre>
    </blockquote>
    Do you mean just using the utilities (brctl, iproute) on demand and
    not keeping any network configuration<br>
    on vdsm host?  Then manager needs reconfigure network on every host
    reboot. Actually,  I like this way. <br>
    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.<br>
    <br>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <blockquote
      cite="mid:1116612527.8262080.1352645203913.JavaMail.root@redhat.com"
      type="cite">
      <pre wrap="">

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
<a class="moz-txt-link-abbreviated" href="mailto:vdsm-devel@lists.fedorahosted.org">vdsm-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel">https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>