On 12/19/19 5:36 AM, Nir Soffer wrote:
When connecting to qemu NBD server during incremental backup, client needs to
register this meta context:
"qemu:dirty-bitmap:backup-sda"
To get dirty bitmap chunks in NBD_CMD_BLOCK_STATUS for export "sda".
This comes from libvirt code creating a backup node named "backup-sda"
for drive "sda",
and creating a temporary dirty bitmap with the same name, which is reasonable.
The name shown here is the bitmap name; libvirt can create any temporary
bitmap name if that is easier to use. Also, while connecting your NBD
client, you can use NBD_OPT_LIST_META_CONTEXT on the query
"qemu:dirty-bitmap:" to learn which dirty-bitmap name(s) are exported
(for now, qemu exports at most one, but in the future, it could export
more than one).
All clients using this API need to have code like:
# Libvirt uses this name for the dirty bitmap.
dirty_bitmap = "backup-" + export_name
Duplicating the magic libvirt code:
if (incremental) {
dd->incrementalBitmap = g_strdup_printf("backup-%s", dd->domdisk->dst);
We have only one client now[1] so this is not a huge issue, but it is
also easy to fix.
I think what we would like to have instead is:
"qemu:dirty-bitmap:sda"
The libvirt API for backups is not frozen until the 6.0 release, so we
could have libvirt just blindly export a bitmap by this name. The
problem is that this name is not unique - for now, while we only support
one backup job at a time, it doesn't matter what name is in use. But in
the future, when we have multiple backup jobs, we have to start worrying
about whether parallel jobs share a single NBD server (in which case the
export names matter, but for a given export, the bitmap names available
for that export are not constrained by other exports) or multiple NBD
servers (one per backup job). But we ALSO have to worry about
presenting a sane bitmap name over any given export regardless of what
bitmap is being exported: if we have two parallel jobs from different
points in time, we REQUIRE that two different bitmaps be in use between
the two jobs, even if we WANT the NBD client to see the name
'qemu:dirty-bitmap:sda' for both jobs. So our current default of naming
the export name after the bitmap name is not future-friendly.
So clients connecting to NBD server with exportname=sda would find the
dirty bitmap
for this export at the expected name, without the need to depend on
the internal node
name.
It looks like a but in qemu, since:
# @name: Export name. If unspecified, the @device parameter is used as the
# export name. (Since 2.12)
If export name is "sda"...
#
# @writable: Whether clients should be able to write to the device via the
# NBD connection (default false).
# @bitmap: Also export the dirty bitmap reachable from @device, so the
# NBD client can use NBD_OPT_SET_META_CONTEXT with
# "qemu:dirty-bitmap:NAME" to inspect the bitmap. (since 4.0)
This API expect that the user can access it at:
"qemu:dirty-bitmap:sda"
As mentioned in the other thread, this is a doc bug, stemming from when
we removed the x- prefix. I'll reply more there.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org