On Fri, 22 Oct 2010 12:48:38 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > On Thu, 21 Oct 2010 10:26:42 +0100 > "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list