Re: [libvirt] [PATCH] support compressed crashdump of guests

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.