----- Original Message -----
> From: "Itamar Heim" <ih...@redhat.com>
> To: "Saggi Mizrahi" <smizr...@redhat.com>
> Cc: "Alon Bar-Lev" <alo...@redhat.com>, "Simon Grinberg" <si...@redhat.com>,
> "VDSM Project Development"
> <email@example.com>, "Andrew Cathrow" <acath...@redhat.com>
> Sent: Thursday, November 29, 2012 1:06:29 PM
> Subject: Re: [vdsm] MTU setting according to ifcfg files.
> On 11/28/2012 01:20 PM, Saggi Mizrahi wrote:
> >>> VDSM should not bother with the issue at all, certainly not
> >>> playing
> >>> a
> >>> guessing game.
> >>> Livant, your 0.02$?
> >> This exactly the reason why we should either define completely
> >> stateless slave host, and apply configuration including what you
> >> call 'defaults'.
> > Completely stateless is problematic because if the engine is down
> > or unavailable and VDSM happens to restart you can't use any of
> > your resources.
> that's actually a very good point. going forward we would like to be
> able for hosts to continue working when engine is down, even post
> reboot. engine passing the policy to the hosts and hosts assuming
> policy is relevant post boot would allow that.
> (though relying on central network services like qunatum will also
> an issue for this architecture).
> > The way forward is currently to get rid of most of the
> > configuration in vdsm.conf.
> > Only have things that are necessary for communication with the
> > engine (eg. Core dump on\off, management interface\port, SSL
> > on\off).
> > Other VDSM configuration should have a an API introduced to set
> > them and that will be persisted but only configurable by
> > management (eg. reserved host mem, guest ram overhead, migration
> > timeouts).
> > There should be a place where VDSM saves the configuration of owned
> > resources (eg. managed storage connections, managed interfaces).
> > This will be use by VDSM to make sure that the resources are
> > configured properly after restarts\downtimes without the need of
> > the engine.
> > To reiterate, the general logic for system resources should be that
> > resources are either owned or used by VDSM, you never share
> > ownership.
> > Never assume ownership unless expressly given. VDSM has complete
> > control over owned resources. VDSM has NO control over unowned
> > resources, he can use them but never configure them.
> > Every other hybrid scheme is just asking for trouble.
> >> Or, store configuration before we perform any change so we can
> >> revert.
> >> Assuming manual changes and distro specific persistence make the
> >> problem complex in factor of np complete, as we do not know what
> >> was
> >> changed when and how to revert.
> >> Itamar though a bomb that we should co-exist on generic host, this
> >> is
> >> something I do not know to compute. I still waiting for a response
> >> of where this requirement came from and if that mandatory.
> > It's all about resource provisioning and ownership delegation.
> hybrid mode is something brought up several times as a use case we
> should consider. so far our main concern was that SLA in the host
> be needed (cgroup for example) between the native and guest
> as well as making sure hybrid nodes will not contend for critical
> resources to reduce the risk of a need to fence them.
brought up - ok.
should be supported - this is the question.
there is no problem to wrap the original server within vm and solve the problem
with current terms.
vdsm-devel mailing list