Re: qemu implementation details leaks to NBD client

[Eric Blake]

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