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