Current implementation of virDomainBlockPull is actually a subset of virDomainBlockRebase with NULL base.
I suggest to add new generalised API call virDomainBlockRebase2 which will serve as a superset of both and support params list.
Having params list is more flexible and extendible for future possible improvements of qemu block-stream or block-copy. Could you please outline your motivations to do this besides the last paragraph?
I'm asking because I personally think that virDomainBlockRebase trying to "magically" do either block-stream or block-copy was a mistake.
The mistake was partially rectified by having virDomainBlockCopy as the proper endpoint for block-copy/blockdev-mirror.
We do lack a fully-featured interface for 'block-stream' (to do intermediate layer pull) but I don't think the fix for it is to have once again a API that does both.
Peter, thank you for your review. Actually, you're totally right - that was my initial motivation: to provide better interface for 'block-stream'. I agree we don't have to mix stream and copy within single API call. I'll prepare v2 patchset with 'block-stream'-only API and keep in mind all your code related comments. Best regards, Nikolai