[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:12:46 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
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?
Thank you,
Peter