Re: [libvirt] [BUG] mlock support breakage

On Wed, 15 Mar 2017 10:11:50 +0100 Andrea Bolognani wrote: > On Wed, 2017-03-15 at 08:59 +0100, Jiri Denemark wrote: > > > > Removing all memory locking limits should be something that > > > > admins very carefully opt-in into, because of the potential > > > > host DoS

Re: [libvirt] [BUG] mlock support breakage

On Wed, 15 Mar 2017 14:29:13 -0400 Luiz Capitulino wrote: > > ... we could consider to be the explicit request for > > setting an infinite memory locking limit and letting users set a lower > > limit with hard_limit if they want. > > That's exactly how I see it! It

Re: [libvirt] [BUG] mlock support breakage

On Wed, 15 Mar 2017 08:59:34 +0100 Jiri Denemark wrote: > On Tue, Mar 14, 2017 at 15:54:25 -0400, Luiz Capitulino wrote: > > On Tue, 14 Mar 2017 20:28:12 +0100 > > Andrea Bolognani wrote: > > > > > On Tue, 2017-03-14 at 14:54 -0400, Luiz Capitulino

Re: [libvirt] [BUG] mlock support breakage

On Wed, 2017-03-15 at 08:59 +0100, Jiri Denemark wrote: > > > Removing all memory locking limits should be something that > > > admins very carefully opt-in into, because of the potential > > > host DoS consequences. Certainly not the default. > >  > > There's no opt-in with , it is mandatory to

Re: [libvirt] [BUG] mlock support breakage

On Tue, Mar 14, 2017 at 15:54:25 -0400, Luiz Capitulino wrote: > On Tue, 14 Mar 2017 20:28:12 +0100 > Andrea Bolognani wrote: > > > On Tue, 2017-03-14 at 14:54 -0400, Luiz Capitulino wrote: > > > > It's unfortunate that the current, buggy behavior made > > > > it look like

Re: [libvirt] [BUG] mlock support breakage

On Tue, 14 Mar 2017 20:28:12 +0100 Andrea Bolognani wrote: > On Tue, 2017-03-14 at 14:54 -0400, Luiz Capitulino wrote: > > > It's unfortunate that the current, buggy behavior made > > > it look like you didn't necessarily have to worry about > > > this. If we fix it,

Re: [libvirt] [BUG] mlock support breakage

On Tue, 2017-03-14 at 14:54 -0400, Luiz Capitulino wrote: > > It's unfortunate that the current, buggy behavior made > > it look like you didn't necessarily have to worry about > > this. If we fix it, existing guests will fail to start > > right away instead of possibly crashing in the future: > >

Re: [libvirt] [BUG] mlock support breakage

On Tue, 14 Mar 2017 19:40:38 +0100 Andrea Bolognani wrote: > It's unfortunate that the current, buggy behavior made > it look like you didn't necessarily have to worry about > this. If we fix it, existing guests will fail to start > right away instead of possibly crashing in

Re: [libvirt] [BUG] mlock support breakage

On Tue, 2017-03-14 at 15:55 +0100, Peter Krempa wrote: > > NB if we did enforce $RAM + $LARGE_NUMBER, then I'd suggest we did > > set a default hard_limit universally once more, not only set a mlock >  > We were already attempting to do this and we reverted it since there's > no deterministic

Re: [libvirt] [BUG] mlock support breakage

On Mon, Mar 13, 2017 at 18:16:49 +, Daniel Berrange wrote: > On Mon, Mar 13, 2017 at 02:08:30PM -0400, Luiz Capitulino wrote: > > On Mon, 13 Mar 2017 13:53:33 -0400 > > Luiz Capitulino wrote: > > > > > OK, you're right. I personally don't like we're putting a random

Re: [libvirt] [BUG] mlock support breakage

On Mon, 2017-03-13 at 14:24 -0400, Luiz Capitulino wrote: > > NB if we did enforce $RAM + $LARGE_NUMBER, then I'd suggest we did > > set a default hard_limit universally once more, not only set a mlock > > limit when using . This would at least ensure we see consistent > > (bad) behaviour rather

Re: [libvirt] [BUG] mlock support breakage

On Mon, 13 Mar 2017 18:16:49 + "Daniel P. Berrange" wrote: > On Mon, Mar 13, 2017 at 02:08:30PM -0400, Luiz Capitulino wrote: > > On Mon, 13 Mar 2017 13:53:33 -0400 > > Luiz Capitulino wrote: > > > > > OK, you're right. I personally don't like

Re: [libvirt] [BUG] mlock support breakage

On Mon, Mar 13, 2017 at 02:08:30PM -0400, Luiz Capitulino wrote: > On Mon, 13 Mar 2017 13:53:33 -0400 > Luiz Capitulino wrote: > > > OK, you're right. I personally don't like we're putting a random cap > > on QEMU memory allocations, but if it's large enough it shouldn't

Re: [libvirt] [BUG] mlock support breakage

On Mon, 13 Mar 2017 13:53:33 -0400 Luiz Capitulino wrote: > OK, you're right. I personally don't like we're putting a random cap > on QEMU memory allocations, but if it's large enough it shouldn't be > a problem (I hope). The I hope part meaning, if we do find legitimate

Re: [libvirt] [BUG] mlock support breakage

On Mon, 13 Mar 2017 16:43:46 + "Daniel P. Berrange" wrote: > On Mon, Mar 13, 2017 at 12:35:42PM -0400, Luiz Capitulino wrote: > > On Mon, 13 Mar 2017 16:08:58 + > > "Daniel P. Berrange" wrote: > > > > > > 2. Drop change c2e60ad0e51 and

Re: [libvirt] [BUG] mlock support breakage

On Mon, Mar 13, 2017 at 12:35:42PM -0400, Luiz Capitulino wrote: > On Mon, 13 Mar 2017 16:08:58 + > "Daniel P. Berrange" wrote: > > > > 2. Drop change c2e60ad0e51 and automtically increase memory > > > locking limit to infinity when seeing > > > > > >pros:

Re: [libvirt] [BUG] mlock support breakage

On Mon, 13 Mar 2017 16:08:58 + "Daniel P. Berrange" wrote: > On Mon, Mar 13, 2017 at 11:58:24AM -0400, Luiz Capitulino wrote: > > > > Libvirt commit c2e60ad0e51 added a new check to the XML validation > > logic where XMLs containing must also > > contain . This causes

Re: [libvirt] [BUG] mlock support breakage

On Mon, Mar 13, 2017 at 11:58:24AM -0400, Luiz Capitulino wrote: > > Libvirt commit c2e60ad0e51 added a new check to the XML validation > logic where XMLs containing must also > contain . This causes two breakages where > working guests won't start anymore: > > 1. Systems where mlock limit was

[libvirt] [BUG] mlock support breakage

Libvirt commit c2e60ad0e51 added a new check to the XML validation logic where XMLs containing must also contain . This causes two breakages where working guests won't start anymore: 1. Systems where mlock limit was set in /etc/security/limits.conf 2. Guests using hugeTLB pages. In this case,