Am 10.10.2011 um 08:52 schrieb Jan Kiszka <jan.kis...@web.de>: > 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.
Through gdb you access virtual address space, whilein this case you really want physical. All you need to create a core file is a memory dump and a register dump. For registers, gdb sounds like a good interface. For memory, why not just use pmemsave? Maybe add a monitor/qmp command that tells you all ram regions, so pmemsave can be invoked intelligently. The alternative to all this is obviously an in-qemu 'core' command that creates core files inside of qemu. That's where I think it really belongs to. Libvirt is a management tool stack, not a "I don't like to work on qemu code so I push code to the layer on top" mesh of things. Or at least that's how it's really supposed to be :). Alex >
