Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace

[Petr Tesarik <ptesarik@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 2880 bytes --]

On Thu, 12 May 2016 11:09:02 +0100
Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Tue, May 10, 2016 at 01:55:10PM +0200, Petr Tesarik wrote:
> > On Tue, 10 May 2016 10:56:42 +0100
> > Stefan Hajnoczi <stefanha@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 <eblake@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.

The one that started my thinking was "makedumpfile". I'm also exploring
ways of writing a standalone eppic application on top of libkdumpfile,
and, of course, you can use libkdumpfile python bindings today already
to write an analysis tool in python which will work equally well on
dumps and live VMs.

Petr T

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]