On Tue, May 10, 2016 at 01:55:10PM +0200, Petr Tesarik wrote: > On Tue, 10 May 2016 10:56:42 +0100 > Stefan Hajnoczi <stefa...@gmail.com> wrote: > > > On Tue, May 10, 2016 at 07:59:41AM +0200, Petr Tesarik wrote: > > > On Mon, 9 May 2016 09:52:28 -0600 > > > Eric Blake <ebl...@redhat.com> wrote: > > > > > > > On 05/07/2016 05:32 PM, Nan Li wrote: > > > > > When running the command "dump-guest-memory", we usually need a large > > > > > space > > > > > of storage to save the dumpfile into disk. It costs not only much > > > > > time to > > > > > save a file in some of hard disks, but also costs limited storage in > > > > > host. > > > > > In order to reduce the saving time and make it convenient for users > > > > > to dump > > > > > the guest memory, we introduce a Filesystem in Userspace (FUSE) to > > > > > save the > > > > > dump file in RAM. It is selectable in the configure file, adding a > > > > > compiling > > > > > of package "fuse-devel". It doesn't change the way of dumping guest > > > > > memory. > > > > > > > > Why introduce FUSE? Can we reuse NBD instead? > > > > > > Let me answer this one, because it's me who came up with the idea, > > > although I wasn't involved in the actual implementation. > > > > > > The idea is to get something more like Linux's /proc/kcore, but for a > > > QEMU guest. So, yes, the same idea could be implemented as a standalone > > > application which talks to QEMU using the gdb remote protocol and > > > exposes the data in a structured form through a FUSE filesystem. > > > > > > However, the performance of such a solution cannot get even close to > > > that of exposing the data directly from QEMU. Maybe it's still the best > > > way to start the project... > > > > If you want no overhead and are willing to pause the guest, use QEMU's > > gdb stub (directly, no extra FUSE file system layer). > > Well, the obvious downside of this solution is that you need GDB > protocol support. AFAIK there are more tools which can work with ELF > dump files than with the GDB protocol. Sure, I could add GDB protocol > support to each and every one of them, but I fail to see how that is > better use of time than adding an additional layer which allows to use > any ELF-capable tool directly.
Out of interest, which tools are you thinking about? I use gdb and crash. Would be interesting to learn about additional options that you are familiar with. Stefan
signature.asc
Description: PGP signature
