[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: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace |
Date: |
Tue, 10 May 2016 09:39:36 +0100 |
User-agent: |
Mutt/1.6.0 (2016-04-01) |
On Tue, May 10, 2016 at 08:19:38AM +0200, Petr Tesarik wrote:
> On Mon, 9 May 2016 17:32:50 +0100
> "Daniel P. Berrange" <address@hidden> wrote:
>
> > 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" <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?).
> >
> > 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.
>
> It's not the same kind of beast:
>
> 1. You need double the amount of RAM in the host. Oh, yes, some
> folks like to create VMs with a RAM size of a few hundred GBs of
> RAM, and then it may not be negligible...
>
> 2. The memory must still be copied. This is made a bit worse by the
> fact that tmpfs does not pre-allocate enough RAM, so even copying
> a few GBs takes several seconds.
>
> 3. Most importantly, if the file is created on the fly, it's a live
> memory source, i.e. repeated reads will reflect changes in the
> running guest.
>
> Some use cases are substantially slower with the dump-then-use
> approach. For example, makedumpfile can estimate the resulting dump
> size based on data from the running kernel. It reads only a tiny
> portion of system RAM to do the analysis, but since only makedumpfile
> knows the exact addresses, you would still need a full dump for that.
>
> With the FUSE approach, guest pages are served on demand when the
> application requests them.
AFAICT, what you describe here is not what this patch set is actually
doing. This patch isn't modifying the guest-dump-memory monitor command
at all - it is just mounting a fuse filesystem and saying you use the
guest-dump-memory as normal to write to that filesystem.
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 :|
- [Qemu-devel] [PATCH 0/2] Dump: add a Filesystem in Userspace and command "fuse-mount", Nan Li, 2016/05/09
- Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace, Petr Tesarik, 2016/05/10
- Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace, Daniel P. Berrange, 2016/05/10
- Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace, Petr Tesarik, 2016/05/10
- Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace, Nan Li, 2016/05/10
- Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace, Stefan Hajnoczi, 2016/05/10
- Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace, Nan Li, 2016/05/10
- Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace, Petr Tesarik, 2016/05/10
- Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace, Stefan Hajnoczi, 2016/05/12
- Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace, Petr Tesarik, 2016/05/12
[Qemu-devel] [PATCH 2/2] Dump: add command "fuse-mount", Nan Li, 2016/05/09