From: "Daniel P. Berrange" <berrange@redhat.com>
To: Petr Tesarik <ptesarik@suse.com>
Cc: Eric Blake <eblake@redhat.com>, Nan Li <nli@suse.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace
Date: Mon, 9 May 2016 17:32:50 +0100 [thread overview]
Message-ID: <20160509163250.GG14467@redhat.com> (raw)
In-Reply-To: <20160509182022.046b8791@hananiah.suse.cz>
On Mon, May 09, 2016 at 06:20:22PM +0200, Petr Tesarik wrote:
> On Mon, 9 May 2016 17:13:07 +0100
> "Daniel P. Berrange" <berrange@redhat.com> 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?).
Maybe I'm missing something, but IIUC the 'dump-guest-memory' monitor
command in QEMU already dumps in ELF format which can be used by standard
ELF tools. If you don't want that dump to hit disk, then you could mount
a tmpfs and then tell QEMU to write to that.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2016-05-09 16:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-07 23:32 [Qemu-devel] [PATCH 0/2] Dump: add a Filesystem in Userspace and command "fuse-mount" Nan Li
2016-05-07 23:32 ` [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace Nan Li
2016-05-09 15:52 ` Eric Blake
2016-05-09 16:13 ` Daniel P. Berrange
2016-05-09 16:20 ` Petr Tesarik
2016-05-09 16:32 ` Daniel P. Berrange [this message]
2016-05-10 6:19 ` Petr Tesarik
2016-05-10 8:39 ` Daniel P. Berrange
2016-05-10 5:59 ` Petr Tesarik
2016-05-10 8:48 ` Daniel P. Berrange
2016-05-10 9:42 ` Petr Tesarik
2016-05-10 11:26 ` Nan Li
2016-05-10 9:56 ` Stefan Hajnoczi
2016-05-10 11:02 ` Nan Li
2016-05-10 11:55 ` Petr Tesarik
2016-05-12 10:09 ` Stefan Hajnoczi
2016-05-12 10:30 ` Petr Tesarik
2016-05-07 23:32 ` [Qemu-devel] [PATCH 2/2] Dump: add command "fuse-mount" Nan Li
2016-05-09 16:30 ` Daniel P. Berrange
2016-05-09 16:48 ` Eric Blake
2016-05-10 11:32 ` Nan Li
2016-05-10 9:47 ` [Qemu-devel] [PATCH 0/2] Dump: add a Filesystem in Userspace and " Stefan Hajnoczi
2016-05-10 9:50 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160509163250.GG14467@redhat.com \
--to=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=nli@suse.com \
--cc=ptesarik@suse.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).