[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/6] qmp: add query-block-dirty-bitmap-ranges
From: |
John Snow |
Subject: |
Re: [Qemu-devel] [PATCH 2/6] qmp: add query-block-dirty-bitmap-ranges |
Date: |
Wed, 10 Feb 2016 10:37:58 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
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.