From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b03Cj-0006e6-7h for qemu-devel@nongnu.org; Tue, 10 May 2016 04:39:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b03Ce-0004Id-7O for qemu-devel@nongnu.org; Tue, 10 May 2016 04:39:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57530) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b03Cd-0004IN-Vf for qemu-devel@nongnu.org; Tue, 10 May 2016 04:39:40 -0400 Date: Tue, 10 May 2016 09:39:36 +0100 From: "Daniel P. Berrange" Message-ID: <20160510083936.GA13377@redhat.com> Reply-To: "Daniel P. Berrange" References: <1462663968-26607-1-git-send-email-nli@suse.com> <1462663968-26607-2-git-send-email-nli@suse.com> <5730B23C.1020009@redhat.com> <20160509161307.GD14467@redhat.com> <20160509182022.046b8791@hananiah.suse.cz> <20160509163250.GG14467@redhat.com> <20160510081938.1b83916f@hananiah.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160510081938.1b83916f@hananiah.suse.cz> Subject: Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Petr Tesarik Cc: Eric Blake , Nan Li , qemu-devel@nongnu.org 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" 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" 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 :|