libvirt users - Jan 2016 - Re: starting a domain only when you have enough resources

On Tue, Jan 26, 2016 at 12:39 PM, Michal Privoznik <mprivozn@redhat.com>
wrote:
> On 26.01.2016 12:30, Andrei Perietanu wrote:
> > Hi all,
> >
> > I am running KVM on a 3.18 kernel. The system runs and Atom processor
> with
> > 2Gb RAM.
> >
> > Using KVM you obviously can over allocate your resources: say you have
4
> > guests each configured with 1GB ram. Running all four at the same
time,
> > depending on the workload, can crash the system - I get a kernel trace
> when
> > this happens.
> >
> > But let's consider a simpler case: one guest with 1.5 Gb RAM,
ubuntu
> 14.03.
> > During the installation the system will again crash.
> > The memory statistics (top or proc/meminfo) will show that the
FreeMemory
> > goes down to 12Mb when this happens - which kind of makes sense
> considering
> > the host will require some RAM to run.
> >
> > But the question is: does libvirt offer any way to prevent this from
> > happening?
> >
> > Some way of not allowing the user to start a guest unless you have
enough
> > free memory. I know how much ram each guest has configured but that is
> not
> > enough. I need to know how much the system has available, and just
> reading
> > the free memory statistic does not help much since that is only a
> snapshot
> > - when running a guest you can have 1gb free now, and 10 mb free 2 min
> > later.
> >
> > Any ideas?
>
> There is one option I see, use -mem-prealloc. Either you can passthrough
> it onto qemu commandline [1] or use locked memoryBacking [2]. I advocate
> for the latter though. Not only it will allocate all the memory at qemu
> startup it will also lock it so it won't get swapped off.
>
> Michal
>
> 1: http://libvirt.org/drvqemu.html#qemucommand
> 2: http://libvirt.org/formatdomain.html#elementsMemoryBacking
>
I tried memoryBacking: I added this to the domain xml:
<memoryBacking>
  <locked/>
</memoryBacking>

And got an error when attempting to start the vm: memory locking no
supported by QEMU binary.

Aside from that I don't really understand how this helps solve my issue -
if you don't mind going a bit into details I'd appreciate it.

Thanks!
Andrei

-- 
 

The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material. Any review, retransmission, dissemination or other use of or 
taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you receive 
this in error please contact the sender and delete the material from any 
computer immediately. It is the policy of Klas  Limited to disavow the 
sending of offensive material and should you consider that the material 
contained in the message is offensive you should contact the sender 
immediately and also your I.T. Manager.

Klas Telecom Inc., a Virginia Corporation with offices at 1101 30th St. NW, 
Washington, DC 20007.

Klas Limited (Company Number 163303) trading as Klas Telecom, an Irish 
Limited Liability Company, with its registered office at Fourth Floor, One 
Kilmainham Square, Inchicore Road, Kilmainham, Dublin 8, Ireland.

On 26.01.2016 14:35, Andrei Perietanu wrote:
> On Tue, Jan 26, 2016 at 12:39 PM, Michal Privoznik
<mprivozn@redhat.com>
> wrote:
> 
>> On 26.01.2016 12:30, Andrei Perietanu wrote:
>>> Hi all,
>>>
>>> I am running KVM on a 3.18 kernel. The system runs and Atom
processor
>> with
>>> 2Gb RAM.
>>>
>>> Using KVM you obviously can over allocate your resources: say you
have 4
>>> guests each configured with 1GB ram. Running all four at the same
time,
>>> depending on the workload, can crash the system - I get a kernel
trace
>> when
>>> this happens.
>>>
>>> But let's consider a simpler case: one guest with 1.5 Gb RAM,
ubuntu
>> 14.03.
>>> During the installation the system will again crash.
>>> The memory statistics (top or proc/meminfo) will show that the
FreeMemory
>>> goes down to 12Mb when this happens - which kind of makes sense
>> considering
>>> the host will require some RAM to run.
>>>
>>> But the question is: does libvirt offer any way to prevent this
from
>>> happening?
>>>
>>> Some way of not allowing the user to start a guest unless you have
enough
>>> free memory. I know how much ram each guest has configured but that
is
>> not
>>> enough. I need to know how much the system has available, and just
>> reading
>>> the free memory statistic does not help much since that is only a
>> snapshot
>>> - when running a guest you can have 1gb free now, and 10 mb free 2
min
>>> later.
>>>
>>> Any ideas?
>>
>> There is one option I see, use -mem-prealloc. Either you can
passthrough
>> it onto qemu commandline [1] or use locked memoryBacking [2]. I
advocate
>> for the latter though. Not only it will allocate all the memory at qemu
>> startup it will also lock it so it won't get swapped off.
>>
>> Michal
>>
>> 1: http://libvirt.org/drvqemu.html#qemucommand
>> 2: http://libvirt.org/formatdomain.html#elementsMemoryBacking
>>
> 
> I tried memoryBacking: I added this to the domain xml:
> <memoryBacking>
>   <locked/>
> </memoryBacking>
> 
> And got an error when attempting to start the vm: memory locking no
> supported by QEMU binary.
> 
> Aside from that I don't really understand how this helps solve my issue
-
> if you don't mind going a bit into details I'd appreciate it.
> 
Well, it will make qemu to allocate all its memory on the start. So
either the allocation would be successful and domain will run or it
won't and qemu will die immediately.

On the other hand, your kernel is heavily broken too. Instead of
crashing at OOM it should kill a process (usually the one that's
consuming the most memory => qemu in this case).

Michal

On Tue, Jan 26, 2016 at 1:51 PM, Michal Privoznik <mprivozn@redhat.com>
wrote:
> On 26.01.2016 14:35, Andrei Perietanu wrote:
> > On Tue, Jan 26, 2016 at 12:39 PM, Michal Privoznik
<mprivozn@redhat.com>
> > wrote:
> >
> >> On 26.01.2016 12:30, Andrei Perietanu wrote:
> >>> Hi all,
> >>>
> >>> I am running KVM on a 3.18 kernel. The system runs and Atom
processor
> >> with
> >>> 2Gb RAM.
> >>>
> >>> Using KVM you obviously can over allocate your resources: say
you have
> 4
> >>> guests each configured with 1GB ram. Running all four at the
same time,
> >>> depending on the workload, can crash the system - I get a
kernel trace
> >> when
> >>> this happens.
> >>>
> >>> But let's consider a simpler case: one guest with 1.5 Gb
RAM, ubuntu
> >> 14.03.
> >>> During the installation the system will again crash.
> >>> The memory statistics (top or proc/meminfo) will show that the
> FreeMemory
> >>> goes down to 12Mb when this happens - which kind of makes
sense
> >> considering
> >>> the host will require some RAM to run.
> >>>
> >>> But the question is: does libvirt offer any way to prevent
this from
> >>> happening?
> >>>
> >>> Some way of not allowing the user to start a guest unless you
have
> enough
> >>> free memory. I know how much ram each guest has configured but
that is
> >> not
> >>> enough. I need to know how much the system has available, and
just
> >> reading
> >>> the free memory statistic does not help much since that is
only a
> >> snapshot
> >>> - when running a guest you can have 1gb free now, and 10 mb
free 2 min
> >>> later.
> >>>
> >>> Any ideas?
> >>
> >> There is one option I see, use -mem-prealloc. Either you can
passthrough
> >> it onto qemu commandline [1] or use locked memoryBacking [2]. I
advocate
> >> for the latter though. Not only it will allocate all the memory at
qemu
> >> startup it will also lock it so it won't get swapped off.
> >>
> >> Michal
> >>
> >> 1: http://libvirt.org/drvqemu.html#qemucommand
> >> 2: http://libvirt.org/formatdomain.html#elementsMemoryBacking
> >>
> >
> > I tried memoryBacking: I added this to the domain xml:
> > <memoryBacking>
> >   <locked/>
> > </memoryBacking>
> >
> > And got an error when attempting to start the vm: memory locking no
> > supported by QEMU binary.
> >
> > Aside from that I don't really understand how this helps solve my
issue -
> > if you don't mind going a bit into details I'd appreciate it.
> >
>
> Well, it will make qemu to allocate all its memory on the start. So
> either the allocation would be successful and domain will run or it
> won't and qemu will die immediately.
>
> On the other hand, your kernel is heavily broken too. Instead of
> crashing at OOM it should kill a process (usually the one that's
> consuming the most memory => qemu in this case).
>
> Michal
>
Sorry, I said crashing; I meant it spits out a kernel trace. You can still
use the system after it happens. I just want to prevent from happening in
the first place.

Andrei

-- 
 

The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material. Any review, retransmission, dissemination or other use of or 
taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you receive 
this in error please contact the sender and delete the material from any 
computer immediately. It is the policy of Klas  Limited to disavow the 
sending of offensive material and should you consider that the material 
contained in the message is offensive you should contact the sender 
immediately and also your I.T. Manager.

Klas Telecom Inc., a Virginia Corporation with offices at 1101 30th St. NW, 
Washington, DC 20007.

Klas Limited (Company Number 163303) trading as Klas Telecom, an Irish 
Limited Liability Company, with its registered office at Fourth Floor, One 
Kilmainham Square, Inchicore Road, Kilmainham, Dublin 8, Ireland.