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

[Petr Tesarik]

On Mon, 9 May 2016 17:13:07 +0100
"Daniel P. Berrange" <address@hidden> wrote:

> On Mon, May 09, 2016 at 09:52:28AM -0600, Eric Blake 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?
> 
> The commit message talks of letting QEMU dump to RAM avoiding disk I/O.
> IOW, it seems like it could just dump to any tmpfs directory.
> 
> I'm not really seeing a compelling reason why QEMU needs to mount a fuse
> filesystem itself - whatever app is using QEMU could handle mounting of
> fs without QEMU's involvement at all.

The ultimate goal is to export internal QEMU state (memory content,
register values) as an ELF file, so you could simply reuse any existing
tools that can work with ELF dump files (gdb, crash, makedumpfile,
readelf, etc.) instead of re-inventing the wheel for each of those
tools.

This cannot be really done from outside of QEMU without too much
overhead (how would you access guest memory from outside QEMU?).

And since this information should be available as an ELF file, it
cannot be achieved with NBD, because that's a (raw) block device.

Petr T