qemu-devel
[Top][All Lists]
Advanced

[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: Nan Li
Subject: Re: [Qemu-devel] [PATCH 1/2] Dump: introduce a Filesystem in Userspace
Date: Tue, 10 May 2016 05:02:53 -0600

>>> On 5/10/2016 at 5:56 PM, Stefan Hajnoczi <address@hidden> 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 <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...
> 
> 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






reply via email to

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