[libvirt] [PATCH] support compressed crashdump of guests

[Daniel P. Berrange]

On Thu, Oct 21, 2010 at 10:35:10AM +0200, Daniel Veillard wrote:
> On Thu, Oct 21, 2010 at 12:02:11PM +0900, KAMEZAWA Hiroyuki wrote:
> > 
> > Now, virsh dump doesn't support compresses dump.
> > This patch adds GZIP and LZOP option to virsh dump and support
> > it at qemu coredump. (AFAIK, LZOP is available on RHEL6.)
> > 
> > When I did 4G guest dump,
> > (Raw)	3844669750 
> > (Gzip)	1029846577
> > (LZOP)	1416263880 (faster than gzip in general)
> > 
> > This will be a help for a host where crash-dump is used
> > and several guests works on it.
> > 
> > help message is modified as this.
> >   NAME
> >     dump - dump the core of a domain to a file for analysis
> > 
> >   SYNOPSIS
> >     dump [--live] [--crash] [--gzip] [--lzop] <domain> <file>
> > 
> >   DESCRIPTION
> >     Core dump a domain.
> > 
> >   OPTIONS
> >     --live           perform a live core dump if supported
> >     --crash          crash the domain after core dump
> >     --gzip           gzip dump(only one compression allowed
> >     --lzop           lzop dump(only one compression allowed
> >     [--domain] <string>  domain name, id or uuid
> >     [--file] <string>  where to dump the core
> > 
> > Tested on Fedora-13+x86-64.
> > 
> > Note: for better compression, we may have to skip pages filled by
> > zero or freed pages. But it seems it's qemu's works.
> 
>   The patch looks relatively simple and clean, I still have one comemnt
> below though. It also seems to me that any use of the dump need a follow
> up decompression before it can be fed to debug tools (gdb ...) as I
> don't think they handle compressed dumps natively.
> 
>   The other comment on principle about this patch is that for saving
> compression we use a qemu.conf option, maybe we should instead use
> a new option there for core compression, or simply reuse the same
> option for both (core being just a special kind of save). You will
> also note that save_image_format takes more options than lzop or gzip.
> If doing so one doesn't need to change virsh too.
> 
>   It's a trade off. If using the configuration option you need to plan
> in advance the fact you will be dumping compressed core, if you expose
> it at the API level itself, you can activate it anytime, and that may be
> more useful for example when interacting with a customer facing an
> issue needing debug. So both ways are acceptable to me.

IMHO, we should follow the same style for save/restore and core dump.
As you say save/restore setup compression in qemu.conf & we should
do the same for core dump, allowing all the same formats. Compression 
is the kind of thing you just want enabled all the time. I don't see
anyone who is going to pick & choose different compression algorithms
per API call, so exposing all the compression methods is just using
up a significant portion of the flag space for little real world gain.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|