[libvirt] [PATCH] qemu: Drop qemuDomainMemoryLimit

Daniel P. Berrange berrange at redhat.com
Fri Aug 9 13:17:59 UTC 2013


On Fri, Aug 09, 2013 at 07:13:58AM -0600, Eric Blake wrote:
> On 08/09/2013 06:56 AM, Michal Privoznik wrote:
> > This function is to guess the correct limit for maximal memory
> > usage by qemu for given domain. This can never be guessed
> > correctly, not to mention all the pains and sleepless nights this
> > code has caused. Once somebody discovers algorithm to solve the
> > Halting Problem, we can compute the limit algorithmically. But
> > till then, this code should never see the light of the release
> > again.
> > ---
> >  src/qemu/qemu_cgroup.c  |  3 +--
> >  src/qemu/qemu_command.c |  2 +-
> >  src/qemu/qemu_domain.c  | 49 -------------------------------------------------
> >  src/qemu/qemu_domain.h  |  2 --
> >  src/qemu/qemu_hotplug.c |  2 +-
> >  5 files changed, 3 insertions(+), 55 deletions(-)
> 
> ACK.  Users that put an explicit limit in their XML are taking on their
> own risk at guessing correctly; all other users should not be forced to
> suffer from a bad guess on our part killing their domain.

If we don't understand how to calculate a default limit that works,
how are users with even less knowledge than us, suppose to calculate
an explicit level of their own ?

This limit was designed so that the hosts are not vulnerable to DOS
attack from a compromised QEMU, so removing this is arguably introducing
a security weakness in our default deployment.

I think I'd like to see some feedback / agreement from QEMU developers
that this problem really can't be solved, before we remove it.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list