[libvirt] [PATCH] support compressed crashdump of guests

[KAMEZAWA Hiroyuki]

On Thu, 21 Oct 2010 10:26:42 +0100
"Daniel P. Berrange" <berrange at redhat.com> wrote:

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

IMHO, hibernation(save vm) and coredump has big difference in usage.
Hibernation is a planned one and the system schedules disk space for it.
Coredump is not a planned one and the system has some special area for coredump.
(At least, most of crashdump user has specail disk space for crashdump.)
Usage is not the same and purpose is, either.

1. Assume a case: hibernation use gzip and coredump use "raw"
Hibernation can be slow because it's scheduled one.
Coredump must be fast because the user has to bring the guest up ASAP.

2. Assume a case: hibernation use raw and coredump uses lzop.
A user want to hibernation quickly. But at coredump, the user uses cluster-fail-over
and coredump itself is not need to be fast but disk-space for crashdump
seems to be small.

There are real gain, I think. But ok, if "flag" space is important, I'd like to
only support lzop. Is it ok ?

Thanks,
-Kame