On 12/04/2012 07:49 PM, Simon Grinberg wrote:

----- Original Message -----
From: "Itamar Heim" <ih...@redhat.com>
To: "Dan Kenigsberg" <dan...@redhat.com>
Cc: "Alon Bar-Lev" <alo...@redhat.com>, "VDSM Project Development" 
<vdsm-devel@lists.fedorahosted.org>, "Simon
Grinberg" <si...@redhat.com>, "Andrew Cathrow" <acath...@redhat.com>
Sent: Monday, December 3, 2012 10:56:53 PM
Subject: Re: [vdsm] Back to future of vdsm network configuration

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"
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

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
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
pure hypervisor nodes, but we support plain Linux nodes,
admins are free to `yum upgrade` in the least convenient
latter mode can be the stuff that nightmares are made of, but
allows the flexibility and bleeding-endgeness we all cherish.

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

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

Can I say we have got agreement on oVirt should cover two kinds
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
users.  They could customize it in production, building and
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

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

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

I'd like to see an API that lets us define a persistent initial
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
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
which had rendered our host incommunicado: the management interface
to send these commands -- and only it -- would show up after boot.
increases the probability that after fencing, we'd see the host

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)

For this use case you'll need much more - you'll need host based clustering 
(Assuming your engine is on a self hosted VM), this it a total different ball 

But note that the approach does not contradict that:
1. You always have your admin statefull configuration on host boot - this is 
the idea behind getting back to the original host network configuration (not 
necessary just the management interface) that I've raised in one of the 
numerous threads on this subject. I don't remember if it was on this one or 

you are assuming the engine image didn't come from the "storage network"

2. The stateless configuration coming from the engine is always on top

Anything required to re-run the engine on a host reboot must be part of the 
statefull section and not part of the engine config section.

vdsm-devel mailing list

Reply via email to