On Wed, 02/10 16:57, 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?
Since Stefan has mentioned "the format" I'm working on, yes, I think it will be possible to expose the persistent bitmap through NBD if the driver assigns node-names to the bitmap BDS. Let me prototype this on top of my branch. Fam