[libvirt PATCH 3/6] qemu: block: blockpull param 'top' support in virsh proper

Pavel Mores pmores at redhat.com
Wed Mar 4 14:38:56 UTC 2020


On Wed, Mar 04, 2020 at 03:13:41PM +0100, Peter Krempa wrote:
> 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 at 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.

That's true.  I think this basically means I should drop patches 3 a 4 from
this series (I'll keep them locally as they give me a reasonably easy way to
test my changes), right?

> 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.

Okay, I'll deal with that in due time, I guess when I'm back to working on
snapshot-delete.

	pvl




More information about the libvir-list mailing list