>>> On 5/10/2016 at 5:56 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Tue, May 10, 2016 at 07:59:41AM +0200, Petr Tesarik wrote: >> On Mon, 9 May 2016 09:52:28 ‑0600 >> Eric Blake <ebl...@redhat.com> 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... > > If you want no overhead and are willing to pause the guest, use QEMU's > gdb stub (directly, no extra FUSE file system layer). If you cannot > pause the guest then take a copy of memory with dump‑guest‑memory to > tmpfs. > > There might be a middle‑ground where you can copy‑on‑write pages and let > the guest continue to run, but this is probably not worth the > effort/complexity. >
Yes, pausing the guest and then accessing the guest memory to do the core analysis work is much easier than handing the running guest. Thank you for your thoughts. > I find it hard to see where adding more code or using FUSE would make > things better? > > Stefan
