[libvirt] [PATCH 2/2] qemu: add a max_core setting to qemu.conf for core dump size

Ján Tomko jtomko at redhat.com
Tue Mar 24 07:26:12 UTC 2015


On Mon, Mar 23, 2015 at 08:43:31PM -0400, John Ferlan wrote:
> 
> 
> On 03/18/2015 08:36 AM, Daniel P. Berrange wrote:
> > Currently the QEMU processes inherit their core dump rlimit
> > from libvirtd, which is really suboptimal. This change allows
> > their limit to be directly controller from qemu.conf instead.
> > ---
> >  src/libvirt_private.syms           |  2 ++
> >  src/qemu/libvirtd_qemu.aug         |  1 +
> >  src/qemu/qemu.conf                 | 12 ++++++++++++
> >  src/qemu/qemu_conf.c               |  3 +++
> >  src/qemu/qemu_conf.h               |  2 ++
> >  src/qemu/qemu_process.c            |  2 ++
> >  src/qemu/test_libvirtd_qemu.aug.in |  1 +
> >  src/util/vircommand.c              | 14 ++++++++++++++
> >  src/util/vircommand.h              |  1 +
> >  src/util/virprocess.c              | 35 +++++++++++++++++++++++++++++++++++
> >  src/util/virprocess.h              |  1 +
> >  11 files changed, 74 insertions(+)
> > 
> > diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> > index ca3520d..7446357 100644
> > --- a/src/libvirt_private.syms
> > +++ b/src/libvirt_private.syms
> > @@ -1240,6 +1240,7 @@ virCommandSetErrorFD;
> >  virCommandSetGID;
> >  virCommandSetInputBuffer;
> >  virCommandSetInputFD;
> > +virCommandSetMaxCoreSize;
> >  virCommandSetMaxFiles;
> >  virCommandSetMaxMemLock;
> >  virCommandSetMaxProcesses;
> > @@ -1951,6 +1952,7 @@ virProcessRunInMountNamespace;
> >  virProcessSchedPolicyTypeFromString;
> >  virProcessSchedPolicyTypeToString;
> >  virProcessSetAffinity;
> > +virProcessSetMaxCoreSize;
> >  virProcessSetMaxFiles;
> >  virProcessSetMaxMemLock;
> >  virProcessSetMaxProcesses;
> > diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
> > index 62951da..029a55a 100644
> > --- a/src/qemu/libvirtd_qemu.aug
> > +++ b/src/qemu/libvirtd_qemu.aug
> > @@ -71,6 +71,7 @@ module Libvirtd_qemu =
> >                   | bool_entry "set_process_name"
> >                   | int_entry "max_processes"
> >                   | int_entry "max_files"
> > +                 | int_entry "max_core"
> >  
> >     let device_entry = bool_entry "mac_filter"
> >                   | bool_entry "relaxed_acs_check"
> > diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
> > index 1c589a2..12e4326 100644
> > --- a/src/qemu/qemu.conf
> > +++ b/src/qemu/qemu.conf
> > @@ -390,6 +390,18 @@
> >  #max_processes = 0
> >  #max_files = 0
> >  
> > +# If max_core is set to a positive integer, then QEMU will be
> > +# permitted to create core dumps when it crashes, provided its
> > +# RAM size is smaller than the limit set. Be warned that the
> > +# core dump will include a full copy of the guest RAM, so if
> > +# the largest guest is 32 GB in size, the max_core limit will
> > +# have to be at least 33/34 GB to allow enough overhead.
> > +#
> > +# By default it will inherit core limit from libvirtd, which
> > +# is usually set to 0 by systemd/init.
> > +#
> > +# Size is in bytes
> > +#max_core = 0
> 
> It's too bad it cannot be a "sized" value... Reading 20G in a file for
> me is so much easier than the comparable byte value say nothing if we
> get to 128G, 1T, etc. (some day).
> 

Having the option as a string would also allow non-integer values, like
"unlimited".

Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150324/b37679c1/attachment-0001.sig>


More information about the libvir-list mailing list