Re: [Qemu-devel] [PATCH 2/6] qmp: add query-block-dirty-bitmap-ranges

[John Snow]

On 02/10/2016 10:36 AM, Denis V. Lunev wrote:
> On 02/10/2016 06:26 PM, John Snow wrote:
>>
>> On 02/10/2016 08:57 AM, Denis V. Lunev wrote:
>>> On 02/10/2016 01:08 PM, Stefan Hajnoczi wrote:
>>>> On Sat, Jan 30, 2016 at 01:56:30PM +0300, Vladimir Sementsov-Ogievskiy
>>>> wrote:
>>>>> Add qmp command to query dirty bitmap contents. This is needed for
>>>>> external backup.
>>>>>
>>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
>>>>> ---
>>>>>    block/dirty-bitmap.c         | 55
>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>>    blockdev.c                   | 62
>>>>> ++++++++++++++++++++++++++++++++++++++++++++
>>>>>    include/block/dirty-bitmap.h |  7 +++++
>>>>>    qapi/block-core.json         | 54
>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>    qmp-commands.hx              | 33 +++++++++++++++++++++++
>>>>>    5 files changed, 211 insertions(+)
>>>> This API produces large replies and/or requires many calls to fetch all
>>>> bitmap data.  The worst case is a 101010... bitmap.
>>>>
>>>> I consider the dirty bitmap to be data (vs control) and not something
>>>> that should be sent over a control channel like the QMP monitor.
>>>>
>>>> How about writing the dirty bitmap to a file?  The new bitmap file
>>>> format that Fam is working on could be used.  That way the dirty bitmap
>>>> can be saved asynchronously without hogging the QMP monitor.
>>> Reasonable point.
>>>
>>> May be it would be better to setup "special" NBD server inside
>>> QEMU which will allow to directly "read" bitmap data.
>>>
>>> Any opinion?
>>>
>>> Den
>> Or perhaps something like migration, where the client receiving the data
>> opens a socket of some sort, and QEMU connects to that socket to send
>> the data.
> no. The point is that QEMU should be queried for data.
> May be even via several sockets to provide it in
> parallel.
> 
> Den

I don't follow.

You'd use a QMP command to tell QEMU where to connect to send the data.
You're still "querying" QEMU, it's just not acting as the server for the
data channel.