From: Michal Privoznik <mprivozn@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: libvir-list@redhat.com, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [libvirt] [PATCH] qemu: Drop qemuDomainMemoryLimit
Date: Fri, 09 Aug 2013 15:29:13 +0200 [thread overview]
Message-ID: <5204EEA9.1010002@redhat.com> (raw)
In-Reply-To: <20130809131759.GB2868@redhat.com>
[CC'ing qemu-devel list]
On 09.08.2013 15:17, Daniel P. Berrange wrote:
> 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
>
In libvirt I've introduced a heuristic to guess the maximum limit for a
memory for a given VM definition. The rationale was "it's better to be
safe by default" and not let leaking qemu trash the host. The heuristic
is only used if user has not configured any limit himself. However, over
the time the number of users reporting OOM kills due to my heuristic has
grown. Finally, I've full nose of this problem so I've made a patch [1]
that removes this 'functionality' completely (I'd say it's bug after
all). In the patch you can see the heuristic we've converged to. But Dan
has his point. If libvirt & qemu devels aren't able to come up with
proper heuristic, how can an ordinary user (who doesn't have any
knowledge of code) do so? So before I apply my patch, I want to ask you
guys, what do you think about it.
Michal
1: https://www.redhat.com/archives/libvir-list/2013-August/msg00437.html
next parent reply other threads:[~2013-08-09 13:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ad6173415eb6c51c95645e42b4bafa67cac39986.1376052970.git.mprivozn@redhat.com>
[not found] ` <5204EB16.8020801@redhat.com>
[not found] ` <20130809131759.GB2868@redhat.com>
2013-08-09 13:29 ` Michal Privoznik [this message]
2013-08-09 15:58 ` [Qemu-devel] [libvirt] [PATCH] qemu: Drop qemuDomainMemoryLimit Anthony Liguori
2013-08-09 16:29 ` Daniel P. Berrange
2013-08-19 8:29 ` Michal Privoznik
2013-08-19 9:06 ` Daniel P. Berrange
2013-08-19 10:06 ` Michal Privoznik
2013-08-09 16:32 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5204EEA9.1010002@redhat.com \
--to=mprivozn@redhat.com \
--cc=berrange@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).