[vdsm] Future of Vdsm network configuration
Mark Wu
wudxw at linux.vnet.ibm.com
Wed Nov 14 15:42:21 UTC 2012
On 11/14/2012 07:53 PM, Gary Kotton wrote:
> On 11/14/2012 11:53 AM, Livnat Peer wrote:
>> On 14/11/12 00:28, Adam Litke wrote:
>>> On Sun, Nov 11, 2012 at 09:46:43AM -0500, Alon Bar-Lev wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Dan Kenigsberg"<danken at redhat.com>
>>>>> To: vdsm-devel at 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.
>>>>
>>>> I know this derive some more work, but I don't think it is that
>>>> complex to
>>>> implement and maintain.
>>>>
>>>> Just my 2 cents...
>>> I couldn't disagree more. What you are suggesting requires that we
>>> reimplement
>>> every single networking feature in oVirt by ourselves. If we want
>>> to support
>>> the (absolutely critical) goal of being distro agnostic, then we
>>> need to
>>> implement the same functionality across multiple distros too. This
>>> is more work
>>> than we will ever be able to keep up with. If you think it's hard
>>> to stabilize
>>> the integration of an external networking library, imagine how hard
>>> it will be
>>> to stabilize our own rewritten and buggy version. This is not how
>>> open source
>>> is supposed to work. We should be assembling distinct, modular,
>>> pre-existing
>>> components together when they are available. If NetworkManager has
>>> integration
>>> problems, let's work upstream to fix them. If it's dependencies are
>>> too great,
>>> let's modularize it so we don't need to ship the parts that we don't
>>> need.
>>>
>> I agree with Adam on this one, reimplementing the networking management
>> layer by ourselves using only atoms seems like duplication of work that
>> was already done and available for our use both by NM and by libvirt.
>>
>> Yes, it is not perfect (far from it actually) but I think we better
>> focus our efforts around adding new functionalities to VDSM and
>> improving the current robustness of the code (we have issues regardless
>> of any external component we're using).
>>
>> For the sake of being distribution agnostic I support the original plan
>> proposed by danken, using OVS combined with libvirt virInterface*
>> wrapper.
>
> The addition of OVS is nice and refreshing (it is the new black). The
> issue with OVS is that a controller is required, there are a number of
> proprietary once and there are open source solutions.
> Something/someone needs to configure and manage the OVS. Just adding
> the libvirt support is not enough - in a nut shell this is just a
> matter of setting the network type for the vnic and passing a few
> additional parameters. Managing and assigning physical NICs to OVS is
> interesting and challenging. Do you guys have any thoughts about how
> you want to go about this?
>
Can we just start with running ovs in standalone mode at first? It could
have the basic forward function based on MAC-learning and
bond/vlans/tunnel function by specifying related options when adding a new
port. We could connect each physical nic for vm network with an ovs
bridge, and then the VM can get
external network access. I agree with that without adding a controller,
we can't get a unified control panel. But I think the standalone mode
could fit current oVirt network model well.
Gary, please correct me if I am wrong or any suggestions from you?
Thanks
Mark.
> Thanks
> Gary
>
>
>>
>>
>> Livnat
>>
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
More information about the vdsm-devel
mailing list