----- 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" > <vdsm-devel@lists.fedorahosted.org>, "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 > that > policy is relevant post boot would allow that. > (though relying on central network services like qunatum will also > cause > 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 > would > be needed (cgroup for example) between the native and guest > workloads. > 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 vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
