Re: bitmaps -- copying allocation status into dirty bitmaps

[Vladimir Sementsov-Ogievskiy]

01.11.2019 18:49, Denis Lunev wrote:
> On 11/1/19 4:42 PM, 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.
> original problem was a little bit incorrect. After some thoughts I found
> that this is NOT enough. We should also add zeroed clusters to the
> bitmap to merge! They do cover some data clusters from the original
> image.
> 
> Thus we should either provide "ALLOCATED" bitmap for other purposes,
> and we should supply "CHANGED" which contains allocated AND
> explicitly zeroed clusters.

Actually in terms of Qemu (bdrv_is_allocated) zeroed clusters (in qcow2)
are considered allocated.

BDRV_BLOCK_ALLOCATED is defined as

  * BDRV_BLOCK_ALLOCATED: the content of the block is determined by this
  *                       layer rather than any backing, set by block layer

- so, it's nothing about allocated regions on host disk, it's an internal
concept about is data (or zero) in this layer or in backing.

> 
> Den
>> 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