[libvirt] [PATCH] support compressed crashdump of guests
Daniel P. Berrange
berrange at redhat.com
Thu Oct 21 09:26:42 UTC 2010
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 :|
More information about the libvir-list
mailing list