qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] Enable debugging in a running vServer


From: Peter Lieven
Subject: Re: [Qemu-block] Enable debugging in a running vServer
Date: Fri, 27 Mar 2015 09:19:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Am 27.03.2015 um 09:18 schrieb Kevin Wolf:
> Am 27.03.2015 um 09:12 hat Peter Lieven geschrieben:
>> Am 26.03.2015 um 16:02 schrieb Kevin Wolf:
>>> Am 26.03.2015 um 15:54 hat Peter Lieven geschrieben:
>>>> Hi Block people,
>>>>
>>>> we recently observed some strange I/O stalls on some vServers. I suspect a 
>>>> bug in the target and
>>>> already added some debugging output to libiscsi that could have helped to 
>>>> track the issue.
>>>>
>>>> However, to enable this debugging I would need to call
>>>>
>>>> iscsi_set_log_level
>>>>
>>>> during runtime from the hmp or qmp.
>>>>
>>>> I wonder what would be the best way to do this and/or if it would be 
>>>> interesting to have a generic
>>>> way to tell a block backend to enter debugging whereas I would leave it up 
>>>> to the backend driver
>>>> what exactly that means?
>>>>
>>>> Other option would be to set an enviroment variable during runtime. But as 
>>>> far as I know thats
>>>> not possible.
>>> I think debugging should be controlled with driver-specific options to
>>> bdrv_open(). For changing the debugging options at runtime, we'd need to
>>> provide a way to directly call bdrv_reopen() from the monitor.
>>>
>>> Before this can work, we need some more infrastructure work that even
>>> introduces the concept of QDict *options to bdrv_reopen(). I have
>>> patches to do this, but even though that branch mostly works, it is
>>> still rather messy and not in a mergable state. If you're interested
>>> anyway, it's the blockdev branch in my tree.
>>>
>>> For your immediate case, you'll probably want a downstream ad-hoc hack
>>> rather than waiting for the real thing.
>> That sounds like the best approach. Would it make sense to already
>> introduce a debug option in the options and honour it at least in bdrv_open?
> Yes, I would think so. That part should stay unchanged even if we add
> the bdrv_reopen() part later.

boolean or int (for several verbosities)? ;-)

>
> Kevin




reply via email to

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