On Tue, Mar 24, 2015 at 08:26:12 +0100, Ján Tomko wrote: > 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/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". I definitely vote for an option to set unlimited rather than having to specify a large number to achieve the same effect. > > Jan Peter
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list