Am 14.02.2020 um 19:54 hat John Snow geschrieben: > Hi, what work remains to make this a stable interface, is it known? > > We're having a problem with bitmaps where in some cases libvirt wants to > commit an image back down to a base image but -- for various reasons -- > the bitmap was left enabled in the backing image, so it would accrue new > writes during the commit. > > Normally, when creating a snapshot using blockdev-snapshot, the backing > file becomes RO and all of the bitmaps become RO too. > > The goal is to be able to disable (or enable) bitmaps from a backing > file before (or atomically just before) a commit operation to allow > libvirt greater control on snapshot commit. > > Now, in my own testing, we can reopen a backing file just fine, delete > or disable a bitmap and be done with it -- but the interface isn't > stable, so libvirt will be reluctant to use such tricks. > > Probably a loaded question, but: > > - What's needed to make the interface stable? > - Are there known problem points? > - Any suggestions for workarounds in the meantime?
I think I've asked this before, but I don't remember the answer... What would be the problem with letting the enable/disable command temporarily reopen the backing file read-write, like the commit job  does? Kevin  I mean, I know that this code is wrong strictly speaking because we really should be counting read-write users  rather than blindly making the node read-only at the end of the operation - but somehow it seems to work in practice for commit jobs.  Counting really means just looking at parent BdrvChild links that have WRITE permissions. I guess doing it right would mean getting rid of BlockDriverState.read_only (which is redundant) and using only permissions.