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
