Re: [Qemu-devel] [PATCH] memory: add cmd line option to omit guest memory from qmeu core dump

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

On 07/31/2012 06:07 PM, Anthony Liguori wrote:
> Jason Baron <jbaron@redhat.com> writes:
> 
>> Add a new '[,dump=on|off]' option to the '-m' memory option. When 'dump=off'
>> is specified, guest memory is omitted from the core dump. The default behavior
>> continues to be to include guest memory when a core dump is triggered. In my
>> testing, this brought the core dump size down from 384MB to 6 MB on a 2GB guest.
>> Thanks to Avi Kivity for the command line syntax.

>>  
>>  DEF("m", HAS_ARG, QEMU_OPTION_m,
>> -    "-m megs         set virtual RAM size to megs MB [default="
>> -    stringify(DEFAULT_RAM_SIZE) "]\n", QEMU_ARCH_ALL)
>> +    "-m megs[,dump=on|off]\n"
>> +    "                set virtual RAM size to megs MB [default=" stringify(DEFAULT_RAM_SIZE) "]\n"
>> +    "                use 'dump=off' to omit guest memory from a core dump [default=on]\n",
>> +     QEMU_ARCH_ALL)

> That said, I think this ought to be a -machine option.  ram-size is
> destined to become a machine option which would make -m N short hand for
> -machine ram-size=n anyway.

And hopefully whatever you decide on in 'qemu -help' won't break
existing libvirt, while we move towards newer libvirt avoiding
sensitivities to -help output.

> 
> Otherwise, the patch is nice.  I really like MADV_DONTDUMP.  We've had
> similar requirements in the past and resorted to a really nasty core
> dump parser.  This is much more elegant.

I'm now trying to figure out how beset to expose this functionality in
libvirt XML.  Tying it to -m might imply adding to the //domain/memory
XPath element, while tying it to -machine might imply adding to
//domain/on_crash or even to /domain/devices/emulator.  Thinking a bit
more, //domain/memory is a guest-visible attribute, but this new option
is not (it's really more of a tweak on what to do at the emulator level,
for when qemu crashes, with no impact to the guest itself).  So I'm also
in favor of tying it to -machine rather than -m, if possible (but
libvirt will be able to adapt to whatever you settle on).

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]