[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Petr Tesarik
Subject: Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace
Date: Tue, 10 May 2016 07:59:41 +0200

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...

Regarding NBD ... correct me if I'm wrong, but I've always thought NBD
can be used to export _disks_ from the QEMU instance, not guest RAM

Petr T

Attachment: pgpOjWrXQI1Xh.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]