On 01.11.19 16: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.
Sounds fun, but is there actually any use for this if the only purpose is to work as a source for merge? I mean, it would be interesting if it worked exactly like a perma-RO pseudo-bitmap that whenever you try to get data from it performs a block-status call. But as you say, that would probably be too slow, and it would take a lot of code modifications, so I wonder if there is actually any purpose for this. > 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. All of what you wrote in this mail makes me think it would make much more sense to just add a “block-dirty-bitmap-create-from” job with an enum of targets. (One of which would be “allocated-blocks”.) Max
signature.asc
Description: OpenPGP digital signature
