Adam Litke:
On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote:
On 26/11/12 03:15, Shu Ming wrote:

Thanks for your summary.  I got comments below.

2012-11-25 18:53, Livnat Peer:
Hi All,
We have been discussing $subject for a while and I'd like to summarized
what we agreed and disagreed on thus far.

The way I see it there are two related discussions:

1. Getting VDSM networking stack to be distribution agnostic.
- We are all in agreement that VDSM API should be generic enough to
incorporate multiple implementation. (discussed on this thread: Alon's
suggestion, Mark's patch for adding support for netcf etc.)

- We would like to maintain at least one implementation as the
working/up-to-date implementation for our users, this implementation
should be distribution agnostic (as we all acknowledge this is an
important goal for VDSM).
I also think that with the agreement of this community we can choose to
change our focus, from time to time, from one implementation to another
as we see fit (today it can be OVS+netcf and in a few months we'll use
the quantum based implementation if we agree it is better)

2. The second discussion is about persisting the network configuration
on the host vs. dynamically retrieving it from a centralized location
like the engine. Danken raised a concern that even if going with the
dynamic approach the host should persist the management network
About dynamical retrieving from a centralized location,  when will the
retrieving start? Just in the very early stage of host booting before
network functions?  Or after the host startup and in the normal running
state of the host?  Before retrieving the configuration,  how does the
host network connecting to the engine? I think we need a basic well
known network between hosts and the engine first.  Then after the
retrieving, hosts should reconfigure the network for later management.
However, the timing to retrieve and reconfigure are challenging.

We did not discuss the dynamic approach in details on the list so far
and I think this is a good opportunity to start this discussion...

 From what was discussed previously I can say that the need for a well
known network was raised by danken, it was referred to as the management
network, this network would be used for pulling the full host network
configuration from the centralized location, at this point the engine.

About the timing for retrieving the configuration, there are several
approaches. One of them was described by Alon, and I think he'll join
this discussion and maybe put it in his own words, but the idea was to
'keep' the network synchronized at all times. When the host have
communication channel to the engine and the engine detects there is a
mismatch in the host configuration, the engine initiates 'apply network
configuration' action on the host.

Using this approach we'll have a single path of code to maintain and
that would reduce code complexity and bugs - That's quoting Alon Bar Lev
(Alon I hope I did not twisted your words/idea).

On the other hand the above approach makes local tweaks on the host
(done manually by the administrator) much harder.
I worry a lot about the above if we take the dynamic approach.  It seems we'd
need to introduce before/after 'apply network configuration' hooks where the
admin could add custom config commands that aren't yet modeled by engine.

Any other approaches ?
Static configuration has the advantage of allowing a host to bring itself back
online independent of the engine.  This is also useful for anyone who may want
to deploy a vdsm node in standalone mode.

I think it would be possible to easily support a quasi-static configuration mode
simply by extending the design of the dynamic approach slightly.  In dynamic
mode, the network configuration is passed down as a well-defined data structure.
When a particular configuration has been committed, vdsm could write a copy of
that configuration data structure to /var/run/vdsm/network-config.json.  During
a subsequent boot, if the engine cannot be contacted after activating the
management network, the cached configuration can be applied using the same code
as for dynamic mode.  We'd have to flesh out the circumstances under which this
would happen.

Multiple physical network devices are quite popular in x86 servers now. Can we add some smart algorithm to leverage multiple physical network devices? Say, one specific device for the management network and others for vdsm host networks. By isolating the management and host networks, the vdsm host can maintain a permanent management work and it is much more clean and not bug prone. If the host doesn't get multiple network devices, we should fall back to the traditional way.

I'd like to add a more general question to the discussion what are the
advantages of taking the dynamic approach?
So far I collected two reasons:

-It is a 'cleaner' design, removes complexity on VDSM code, easier to
maintain going forward, and less bug prone (I agree with that one, as
long as we keep the retrieving configuration mechanism/algorithm simple).

-It adheres to the idea of having a stateless hypervisor - some more
input on this point would be appreciated

Any other advantages?

discussing the benefits of having the persisted
As I mentioned above, the main benefit I see of having some sort of persistent
configuration is:

- To allow the host to operate independently of the engine in either a failure
   scenario or in a standalone configuration.

舒明 Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail: or
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, 
Beijing 100193, PRC

vdsm-devel mailing list

Reply via email to