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

[Anthony Liguori]

Eric Blake <address@hidden> writes:

> On 07/31/2012 06:07 PM, Anthony Liguori wrote:
>> Jason Baron <address@hidden> 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.

Ack.

>> 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).

>From a QEMU perspective, I'd eventually like to see memory modeled as
just another type of device.  I would expect host properties (mergable
and don't dump) to be a property of the device.  I don't think forcing a
split between guest/host properties makes a ton of sense here although I
guess it's technically possible.

As a libvirt user, the users that don't want memory to be dumped want it
for all guests.  It's exactly the same as KSM.  Either you want it
everywhere or you don't want it at all.

Regards,

Anthony Liguori

>
> -- 
> Eric Blake   address@hidden    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org