On 29/02/2016 09:54, Paolo Bonzini wrote: > > > On 29/02/2016 09:14, Markus Armbruster wrote: >> I completely agree with you that Get LBA Status cannot just reflect the >> top layer. But that's not what I meant to propose. Let me try to >> explain myself more clearly. >> >> Consider a QCOW2 image D (for delta) with a backing file B (for base). >> If you open it normally, you see "D over B". Get LBA Status should >> certainly claim the "deallocated" state only for blocks that are >> allocated neither in D nor B. >> >> However, you can also open D *without* its backing file. Then you see >> "D over nothing". Here, get LBA Status should claim "deallocated" state >> for anything not allocated in D. > > Ok, this makes more sense. > > The question then is whether to implement this NBD server inside QEMU, > or outside it as a separate process to which QEMU "pushes" blocks as in > the existing backup job. I would prefer the latter, so that it is > possible to implement various APIs (get block status, but also VMware or > Parallels or whatever). > > Basically the same points made in > https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg01969.html > still apply.
Talked a bit to Fam now and I noted Denis's observation that QEMU would still use the backup block job, plus the NBD server as in Fam's fleecing. Then the NBD server is already the push->pull adapter. It's a bit clearer now. Opening D without backing file still feels a bit weird, because the NBD server would provide wrong data for clean blocks. I would think that a "stupid" backup software could always ignore the get LBA status command and get a full backup. Is this a requirement or not, and if not, why? I don't have any particular opinion against an NBD get LBA status command that returns deallocated/allocated _and_ clean/dirty. But reusing one as the other feels like the kind of hack that seems clever and that you regret down the road. I'm not sure whether the clean/dirty status is data plane or control plane either. I don't think the terms have a well-defined meaning in terms of storage. In the networking world, stuff like routing protocols (OSPF, BGP, etc.) is control plane, and based on this analogy dirty bitmaps seem like control plane to me. So I wouldn't rule out QMP-based export of the dirty bitmap---either directly or optimized through a separate socket as in http://article.gmane.org/gmane.comp.emulators.qemu/397083. Dirty bitmaps should also compress well, so perhaps gzip+base64 over JSON might work as well. I'm not saying we certainly won't regret it, but it seems "less different". Don't really know how to put it better... Paolo