On Wed, Mar 04, 2020 at 15:01:07 +0100, Pavel Mores wrote:
On Wed, Mar 04, 2020 at 02:53:53PM +0100, Peter Krempa wrote:
On Wed, Mar 04, 2020 at 14:41:09 +0100, Pavel Mores wrote:
On Wed, Mar 04, 2020 at 01:00:59PM +0100, Peter Krempa wrote:
On Wed, Mar 04, 2020 at 11:12:37 +0100, Pavel Mores wrote:
A new command-line option --top was added to virsh's blockpull command. Similar to how --base is handled, in presence of --top the operation is implemented internally as a rebase. To that end, a corresponding new 'top' parameter was added to virDomainBlockRebase().
Signed-off-by: Pavel Mores <pmores@redhat.com> --- include/libvirt/libvirt-domain.h | 4 ++-- src/libvirt-domain.c | 5 +++-- tools/virsh-domain.c | 14 +++++++++++--- 3 files changed, 16 insertions(+), 7 deletions(-)
[...]
This is obviously a lot of work, thus we need to decide whether adding an old-school API is worth it in the inerim. Are there any real users who would benefit from the new pull semantics? blockpull is around for a long time already, but it seems that commit is favoured.
If there is no real demand though I'd probably prefer if we don't add any more block job APIs any more.
I'm not aware of any real demand for this, however as I stated in the cover letter I believe I need full blockpull to deal with the bug I'm actually working on, which is full support for external snapshots in snapshot-delete.
Deleting/reverting external snapshots needs to be done internally under the hood of virDomainRevertToSnapshot/virDomainSnapshotDelete so if you require use of the 'block-stream' command to an intermediate layer you don't actually need to expose it via virDomainBlockPull/Rebase to take advantage of it. For reversion of external snapshots you'll probably need a new API anyways as you'll need to be able to specify a new set of disk images to hold the writes.