qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
Date: Fri, 07 Oct 2011 17:06:50 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-10-07 16:05, Wen Congyang wrote:
> 于 2011/10/7 20:56, Jan Kiszka 写道:
>> On 2011-10-07 14:25, Wen Congyang wrote:
>>> 于 2011/10/7 18:16, Jan Kiszka 写道:
>>>> 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 device. The
>>>>> reason is that the device's status is also needed to migrate to remote 
>>>>> machine,
>>>>> and the host pci device's status is not stored in qemu. So it is 
>>>>> unmigratable.
>>>>>
>>>>> 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 when 
>>>>> dumping
>>>>> the guest's memory.
>>>>
>>>> Why not simply attach gdb? That works independently of migration.
>>>
>>> If qemu has some problem, we can use gdb to debug it. But if guest os
>>> has problem
>>> (eg:kernel panic and kdump does not work), we should dump guest's memory
>>> and use
>>> crash to analyze.
>>
>> qemu-system-xxx -s (or "gdbserver" via monitor if qemu is already
>> running), gdb vmlinux, then "target remote :1234".
> 
> Hmm, if i use qemu, i can do it as the above. But i can not hope our 
> customer
> do it because it is difficult for them to debug kernel.
> So the customer can use 'virsh dump'(the guest is managed by libvirt) or 
> autodump(if
> the guest has a watchdog) to dump the memory. The supporter can debug 
> kernel in another
> machine.

gdb is surely scriptable. It's just a bit more complex than running
"generate-core-file" - gdb does not yet support this for remote
sessions. Ideally, that feature should be added, and you are done,
independent of QEMU migration format X.Y.whatever or limitations due to
unmigratable devices. The current approach is, well, "pragmatic".

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]