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

[Stefan Hajnoczi]

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