From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDBqp-00019X-95 for qemu-devel@nongnu.org; Mon, 10 Oct 2011 05:08:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDBqn-0001Mr-Md for qemu-devel@nongnu.org; Mon, 10 Oct 2011 05:08:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDBqn-0001Mj-AY for qemu-devel@nongnu.org; Mon, 10 Oct 2011 05:08:45 -0400 Date: Mon, 10 Oct 2011 10:08:26 +0100 From: "Daniel P. Berrange" Message-ID: <20111010090825.GG9408@redhat.com> References: <4E8ECA91.8040409@cn.fujitsu.com> <4E8ED167.1000705@siemens.com> <20111008151622.GA17181@amd.home.annexia.org> <4E916035.5050906@web.de> <20111009102338.GN16799@amd.home.annexia.org> <4E92568E.2010507@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E92568E.2010507@cn.fujitsu.com> Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Luiz Capitulino , Jan Kiszka , "Richard W.M. Jones" , qemu-devel 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 :|