[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bitmaps -- copying allocation status into dirty bitmaps
From: |
Vladimir Sementsov-Ogievskiy |
Subject: |
Re: bitmaps -- copying allocation status into dirty bitmaps |
Date: |
Fri, 1 Nov 2019 16:53:08 +0000 |
01.11.2019 18:42, John Snow wrote:
> Hi, in one of my infamously unreadable and long status emails, I
> mentioned possibly wanting to copy allocation data into bitmaps as a way
> to enable users to create (external) snapshots from outside of the
> libvirt/qemu context.
>
> (That is: to repair checkpoints in libvirt after a user extended the
> backing chain themselves, you want to restore bitmap information for
> that node. Conveniently, this information IS the allocation map, so we
> can do this.)
>
> It came up at KVM Forum that we probably do want this, because oVirt
> likes the idea of being able to manipulate these chains from outside of
> libvirt/qemu.
>
> Denis suggested that instead of a new command, we can create a special
> name -- maybe "#ALLOCATED" or something similar that can never be
> allocated as a user-defined bitmap name -- as a special source for the
> merge command.
>
> You'd issue a merge from "#ALLOCATED" to "myBitmap0" to copy the current
> allocation data into "myBitmap0", for instance.
I can suggest also the following:
We now have
{ 'alternate': 'BlockDirtyBitmapMergeSource',
'data': { 'local': 'str',
'external': 'BlockDirtyBitmap' } }
We may add separate qapy enum
BlockStatusBitmapType = {'allocated', ...}
and struct
BlockStatusBitmap = {'node': 'str', 'type': BlockStatusBitmapType}
and then extend BlockDirtyBitmapMergeSource like
{ 'alternate': 'BlockDirtyBitmapMergeSource',
'data': { 'local': 'str',
'external': 'BlockDirtyBitmap',
'status': 'BlockStatusBitmap' } }
So, we can avoid special name "#ALLOCATED", which we'll have to define
in qcow2 spec and nbd spec.
>
> Some thoughts:
>
> - The only commands where this pseudo-bitmap makes sense is merge.
> enable/disable/remove/clear/add don't make sense here.
>
> - This pseudo bitmap might make sense for backup, but it's not needed;
> you can just merge into an empty/enabled bitmap and then use that.
>
> - Creating an allocation bitmap on-the-fly is probably not possible
> directly in the merge command, because the disk status calls might take
> too long...
>
> Hm, actually, I'm not sure how to solve that one. Merge would need to
> become a job (or an async QMP command?) or we'd need to keep an
> allocation bitmap object around and in-sync. I don't really want to do
> either, so maybe I'm missing an obvious/better solution.
>
> Also, with regards to introspection, if we do create a special reserved
> name like #ALLOCATED, we need to make sure that this is available and
> obvious via the QAPI schema.
>
> --js
>
--
Best regards,
Vladimir