Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest

From: "Daniel P. Berrange" <berrange@redhat.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
	Jan Kiszka <jan.kiszka@web.de>,
	"Richard W.M. Jones" <rjones@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
Date: Mon, 10 Oct 2011 10:08:26 +0100	[thread overview]
Message-ID: <20111010090825.GG9408@redhat.com> (raw)
In-Reply-To: <4E92568E.2010507@cn.fujitsu.com>

On Mon, Oct 10, 2011 at 10:21:02AM +0800, Wen Congyang wrote:
> At 10/09/2011 06:23 PM, Richard W.M. Jones Write:
> > On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote:
> >> As explained in the other replies: It is way more future-proof to use an
> >> interface for this which was designed for it (remote gdb) instead of
> >> artificially relaxing reasonable constraints of the migration mechanism
> >> plus having to follow that format with the post-processing tool.
> > 
> > Any interface that isn't "get this information off my production
> > server *now*" so that I can get the server restarted, and send it to
> > an expert to analyse -- is a poor interface, whether it was designed
> > like that or not.  Perhaps we don't have the right interface at all,
> > but remote gdb is not it.
> 
> What about the following idea?
> 
> Introduce a new monitor command named dump, and this command accepts a filename.
> We can use almost all migration's code. We use this command to dump guest's
> memory, so there is no need to check whether the guest has a unmigratable device.

I think it would be a good idea of QEMU had a dedicated 'dump' command
for this purpose, even if it was just an alias for 'migrate' initially.
I have never really liked the fact that we abuse the 'migrate' command
to generate a core dump. The resulting data file from this is more
complex than it really needs to be, causing complexity for post-processing
it. The needs of migration, are not entirely aligned with the needs of
core dumping in the long term, so we should allow the possibility of
their impls diverging without impacting apps using them.

So adding a 'dump' command which wrote out data in a format that was
optimized for offline processing by tools like 'crash' (or the windows
equivalent) would be a good improvement, even if it just reuses the
migrate code for now.

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 :|