On 12/03/2012 06:54 PM, Dan Kenigsberg wrote:
On Mon, Dec 03, 2012 at 04:28:16PM +0200, Itamar Heim wrote:
On 12/03/2012 04:25 PM, Dan Kenigsberg wrote:
On Mon, Dec 03, 2012 at 04:35:34AM -0500, Alon Bar-Lev wrote:

----- Original Message -----
From: "Mark Wu" <wu...@linux.vnet.ibm.com>
To: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>
Cc: "Alon Bar-Lev" <alo...@redhat.com>, "Dan Kenigsberg" <dan...@redhat.com>, "Simon 
Grinberg" <si...@redhat.com>,
"Antoni Segura Puimedon" <asegu...@redhat.com>, "Igor Lvovsky" <ilvov...@redhat.com>, 
"Daniel P. Berrange"
Sent: Monday, December 3, 2012 7:39:49 AM
Subject: Re: [vdsm] Back to future of vdsm network configuration

On 11/29/2012 04:24 AM, Alon Bar-Lev wrote:

----- Original Message -----
From: "Dan Kenigsberg" <dan...@redhat.com>
To: "Alon Bar-Lev" <alo...@redhat.com>
Cc: "Simon Grinberg" <si...@redhat.com>, "VDSM Project
Development" <vdsm-devel@lists.fedorahosted.org>
Sent: Wednesday, November 28, 2012 10:20:11 PM
Subject: Re: [vdsm] MTU setting according to ifcfg files.

On Wed, Nov 28, 2012 at 12:49:10PM -0500, Alon Bar-Lev wrote:
Itamar though a bomb that we should co-exist on generic host,
something I do not know to compute. I still waiting for a
where this requirement came from and if that mandatory.

This bomb has been ticking since ever. We have ovirt-node images
pure hypervisor nodes, but we support plain Linux nodes, where
admins are free to `yum upgrade` in the least convenient moment.
latter mode can be the stuff that nightmares are made of, but it
allows the flexibility and bleeding-endgeness we all cherish.

There is a different between having generic OS and having generic
setup, running your email server, file server and LDAP on a node
that running VMs.

I have no problem in having generic OS (opposed of ovirt-node) but
have full control over that.

Can I say we have got agreement on oVirt should cover two kinds of
hypervisors?  Stateless slave is good for pure and normal
workload, while generic host can keep the flexibility of
In my opinion, it's good for the oVirt community to provide choices
users.  They could customize it in production, building and even
code according to their requirements and skills.

I also think it will be good to support both modes! It will also good if we can 
rule the world! :)

Now seriously... :)

If we want to ever have a working solution we need to focus, dropping wishful 
requirements in favour of the minimum required that will allow us to reach to 
stable milestone.

Having a good clean interface for vdsm network within the stateless mode, will 
allow a persistent implementation to exists even if the whole implementation of 
master and vdsm assume stateless. This kind of implementation will get a new 
state from master, compare to whatever exists on the host and sync.

I, of course, will be against investing resources in such network
management plugin approach... but it is doable, and my vote is not
something that you cannot safely ignore.

I cannot say that I do not fail to parse English sentences with double
or triple negations...

I'd like to see an API that lets us define a persistent initial management
interface, and create volatile network devices during runtime. I'd love
to see a define/create distiction, as libvirt has.

How about keeping our current setupNetwork API, with a minor change to
its sematics - it would not persist anything. A new persistNetwork API
would be added, intending to persist the management network after it has
been tested.

On boot, only the management defitions would show up, and Engine (or a
small local sevice on top of vdsm) would push the complete

how does this benefit over loading the last config, and then have
engine refresh (always/if needed)?

It's clearer for the local admin: if it's on the file system, it would
be there after boot; he can do his worst to them, and we'd try to

Also, it is easier to recover from utterly-horrible remote commands,
which had rendered our host incommunicado: the management interface used
to send these commands -- and only it -- would show up after boot. This
increases the probability that after fencing, we'd see the host again.

i think we mentioned this before, but this will kill any way to have hosts come back to life, also have a policy on connecting to storage, even if engine is still down. (one of these use cases is for the engine itself to be hosted on the hosts as well)
vdsm-devel mailing list

Reply via email to