From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDBlR-0007Bx-Ua for qemu-devel@nongnu.org; Mon, 10 Oct 2011 05:03:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDBlM-0008H5-3W for qemu-devel@nongnu.org; Mon, 10 Oct 2011 05:03:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDBlL-0008H0-Oo for qemu-devel@nongnu.org; Mon, 10 Oct 2011 05:03:08 -0400 Date: Mon, 10 Oct 2011 10:02:46 +0100 From: "Daniel P. Berrange" Message-ID: <20111010090246.GF9408@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> <4E929618.4040403@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E929618.4040403@web.de> 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: Jan Kiszka Cc: qemu-devel , "Richard W.M. Jones" , Luiz Capitulino On Mon, Oct 10, 2011 at 08:52:08AM +0200, Jan Kiszka wrote: > On 2011-10-10 04:21, 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 do not want to reject this proposal categorically, but I would like to > see the gdb path fail /wrt essential requirements first. So far I don't > see it would. GDB is often forbidden on production servers, so that path is clearly not an option, unless we want libvirt to implement the GDB remote RPC protocol itself which just sounds like a world of hurt. 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 :|