2014-08-15 14:44+0100, Daniel P. Berrange: > On Fri, Aug 15, 2014 at 09:23:35AM -0400, Andrew Theurer wrote: > > > On Thu, Aug 14, 2014 at 01:55:11PM -0400, Andrew Theurer wrote: > > > > > From: "Radim Krčmář" <rkrcmar@xxxxxxxxxx> > > > > > It does not seem to be possible to tune shares and get a good general > > > > > behavior, so the best solution I can see is to disable the cpu cgroup > > > > > and let users do it when needed. (Keeping all tasks in $CG/tasks.) > > > > > > > > Could we have each VM's shares be nr_vcpu * 1024, and the share for > > > > $CG/machine.slice be sum of all VM's share? > > > > > > Realistically libvirt can't change what it does by default for VMs wrt > > > to this cgroups setting, because it would cause an immediate functional > > > change for any who has deployed current libvirt versions & upgrades. > > > > Is this another way of saying, "we have already set a bad precedent, > > so we need to keep it"? I am concerned that anyone who may be experiencing > > this problem may be unsure of what is causing it, and is not aware of how > > to fix it. > > > > > Management apps like oVirt or OpenStack should explicitly set the policy > > > they desire in this respect. > > > > Shouldn't a user or upper level mgmt have some expectation of sane defaults? > > A user or mgmt app has already specified a preference in the number of vcpus > > -shouldn't that be enough? Why have this fix need to be pushed to multiple > > upper layers when it can be remedied in just one (libvirt)? Honestly, I > > don't understand how this even got out the way it is. > > If we hadn't already had this behaviour in libvirt for 3+ years then sure > it would be desirable to change it. At this point though, applications > have been exposed to current semantics for a long time and can have setup > usage policies which are relying on this. If we change the defaults we have > a non-negligible risk of causing regressions in behaviour for our existing > userbase. I think that (enterprise) distributions are for this preservation and upstream is only looking forward, so we don't end in the huge pile that is created throughout years. And if we are trying to prevent changes, we should be especially wary of adding new features. Well, depends on the expected lifetime of libvirt. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list