[libvirt] [PATCH] support compressed crashdump of guests

[KAMEZAWA Hiroyuki]

On Fri, 22 Oct 2010 12:48:38 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu at jp.fujitsu.com> wrote:

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

I discussed my team and decied to start from save_image_format qemu.conf.
Or I'll add dump_image_format configuration in qemu.conf

Thanks,
-Kame