----- 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.
How?, Will you really fire up VMs without central management control? This implies you'll have to go into host based clustering where you'll hit scale limits as any other such a solution. If you do not intend to do the above then why not stateless? Host to remember on wakeup an old configuration may at best not work but at worst may conflict with existing configuration and do unpredictable things to your environment. You also loose the benefit of recovering bad configured host simply by fencing it. > 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. Just few reasons: - One of the key attraction with KVM is that with it, you are capable to run process/application along side virtual machines. Look at every KVM presentation out there. - Licencing and support, some application (do I hear Oracle?) are not licensed/supported on KVM, but you would still want to use free cycles for virtual machines (especially on modern servers) - 3rd party monitoring and audit tools - custom drivers - custom SLA policies - etc, - etc, - etc, You don't want to say, ha if you use VDSM to manage the node you can't do all of the above. Stateless by the way, in a sense that after reboot the node goes back to the original configuration, works very well with the requirement above. This means that the admin sets everything required for the non virtualized hardware, VDSM configures on top, but after reboot all is reverted to the original thus everything else continues to work after reboot. > > 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. > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
