Re: [Qemu-devel] [Qemu-block] KVM Forum block no[td]es

[Nir Soffer]

On Mon, Nov 12, 2018 at 12:25 AM Max Reitz <address@hidden> wrote:

> This is what I’ve taken from two or three BoF-like get-togethers on
> blocky things.  Amendments are more than welcome, of course.

...

> Bitmaps
>
=======
>
> (Got this section from sneaking into a BoF I wasn’t invited to.  Oh
> well.  Won’t hurt to include them here.)
>
> Currently, when dirty bitmaps are loaded, all IN_USE bitmaps are just
> not loaded at all and completely ignored.  That isn’t correct, though,
> they should either still be loaded (and automatically treated and
> written back as fully dirty), or at least qemu-img check should
> “repair” them (i.e. fully dirtying them).
>

I'm not sure making bitmaps dirty is better.

When bitmap is marked IN_USE, it means that we cannot use it for
backup. Deleting the bitmap or making it as bad so it cannot be used
for the next backup is the same. Making the bitmap as dirty will full
the management layer that everything was fine when the next backup
includes the entire disk. It is better to cause the next backup to fail
in a verbose way, since the backup software can recover by doing
a full backup.

Sometimes qemu (running in a mode as bare as possible) is better than
> using qemu-img convert, for instance.  It gives you more control
> (through QMP; you get e.g. better progress reporting), you get all of
> the mirror optimizations (we do have optimizations for convert, too,
> but whether it’s any good to write the same (or different?)
> optimizations twice is another question), and you get a common
> interface for everything (online and offline).
> Note that besides a bare qemu we’ve also always wanted to convert as
> many qemu-img operations into frontends for block jobs as possible.
> We have only done this for commit, however, even though convert looked
> like basically the ideal target.  It was just too hard with too little
> apparent gain, like always (and convert supports additional features
> like concatenation which we don’t have in the runtime block layer
> yet).
>

I'm not sure it is better to run qemu and use qemu-img as thin wrapper
over qmp.

For example, management system may ascociate qemu-img
with a sanlock lease, and sanlock may try to terminate qemu-img when
a lease is invalidated. In this case sanlock will succeed while qemu is till
accessing storage it should not access.
...

> Transacitonable bitmap primitives (e.g. copying a bitmap) would be
> nice so you can use them when creating a snapshot.  Then it’d be up to
> the management layer to make use of them:
> - Do you want to continue using the very same bitmap?  Copy it then
>   (or move it, depending on what exactly you want to do and what
>   primitives there are)
> - Do you want to start with a new bitmap?  Then just create a new one
>   along with the overlay.
>

Having both options sounds good, but we can start with the first.

Nir