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 <vsement...@virtuozzo.com> >>>>> --- >>>>> 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.