From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50446) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDBjX-0005hK-Ep for qemu-devel@nongnu.org; Mon, 10 Oct 2011 05:01:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDBjS-0007oi-R8 for qemu-devel@nongnu.org; Mon, 10 Oct 2011 05:01:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDBjS-0007oH-Hq for qemu-devel@nongnu.org; Mon, 10 Oct 2011 05:01:10 -0400 Date: Mon, 10 Oct 2011 10:00:51 +0100 From: "Daniel P. Berrange" Message-ID: <20111010090051.GE9408@redhat.com> References: <4E8ECA91.8040409@cn.fujitsu.com> <4E8ED167.1000705@siemens.com> <4E8EEFC8.9040606@gmail.com> <4E8EF718.1050402@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E8EF718.1050402@siemens.com> Content-Transfer-Encoding: quoted-printable 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: Wen Congyang , qemu-devel , Luiz Capitulino On Fri, Oct 07, 2011 at 02:56:56PM +0200, Jan Kiszka wrote: > On 2011-10-07 14:25, Wen Congyang wrote: > > =E4=BA=8E 2011/10/7 18:16, Jan Kiszka =E5=86=99=E9=81=93: > >> On 2011-10-07 11:46, Wen Congyang wrote: > >>> Currently, virsh dump uses monitor command migrate to dump guest's = memory > >>> to file, and we can use crash to analyze the file. > >>> > >>> Unfortunately, virsh dump can not work if guest uses host pci devic= e. The > >>> reason is that the device's status is also needed to migrate to rem= ote machine, > >>> and the host pci device's status is not stored in qemu. So it is un= migratable. > >>> > >>> I think we can we can add a option to qmp command migrate(eg: skip= ) to allow > >>> the user to skip the check, and this option should be used only whe= n dumping > >>> the guest's memory. > >> > >> Why not simply attach gdb? That works independently of migration. > >=20 > > If qemu has some problem, we can use gdb to debug it. But if guest os= =20 > > has problem > > (eg:kernel panic and kdump does not work), we should dump guest's mem= ory=20 > > and use > > crash to analyze. >=20 > qemu-system-xxx -s (or "gdbserver" via monitor if qemu is already > running), gdb vmlinux, then "target remote :1234". That is already possible, but that is not what we need for 'virsh dump'. The goal of that API is to provide a coredump of the guest, which can then be analysed off-node/site. While in theory you could attach GDB to the QEMU process and use GDB commands to then write out a coredump this isn't really satisfactory because too many large companies have security/audit compliance rules which forbid installation of developer tools (compilers, debuggers, etc) on production servers. So we cannot assume GDB is available. We need to be able to create a coredump natively from either QEMU or libvirt, with minimal of external tools. Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|