Re: [PATCH 2/6] migration: introduce savevm, loadvm, delvm QMP commands

[Daniel P . Berrangé]

On Fri, Jul 03, 2020 at 04:49:33PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > On Thu, Jul 02, 2020 at 01:12:52PM -0500, Eric Blake wrote:
> > > On 7/2/20 12:57 PM, Daniel P. Berrangé wrote:
> > > > savevm, loadvm and delvm are some of the few commands that have never
> > > > been converted to use QMP. The primary reason for this lack of
> > > > conversion is that they block execution of the thread for as long as
> > > > they run.
> > > > 
> > > > Despite this downside, however, libvirt and applications using libvirt
> > > > has used these commands for as long as QMP has existed, via the
> > > > "human-monitor-command" passthrough command. IOW, while it is clearly
> > > > desirable to be able to fix the blocking problem, this is not an
> > > > immediate obstacle to real world usage.
> > > > 
> > > > Meanwhile there is a need for other features which involve adding new
> > > > parameters to the commands. This is possible with HMP passthrough, but
> > > > it provides no reliable way for apps to introspect features, so using
> > > > QAPI modelling is highly desirable.
> > > > 
> > > > This patch thus introduces trival savevm, loadvm, delvm commands
> > > 
> > > trivial
> > > 
> > > > to QMP that are functionally identical to the HMP counterpart, including
> > > > the blocking problem.
> > > 
> > > Should we name them 'x-savevm', 'x-loadvm', 'x-delvm' to give ourselves 
> > > room
> > > to change them when we DO solve the blocking issue?  Or will the solution 
> > > of
> > > the blocking issue introduce new QMP commands, at which point we can add 
> > > QMP
> > > deprecation markers on these commands to eventually retire them?
> > 
> > I was in two minds about this, so I'm open to arguments either way.
> > 
> > The primary goal is for libvirt to consume the APIs as soon as possible,
> > and generally libvirt doesn't want todo this is they are declared 
> > experimental
> > via a "x-" prefix. So that pushes me away from "x-".
> > 
> > If we don't have an "x-" prefix and want to make changes, we can add extra
> > parameters to trigger new behaviour in backwards compatible manner. Or we 
> > can
> > simply deprecate these commands, deleting them 2 releases later, while 
> > adding
> > completely new commands.
> > 
> > If we think the prposed design will definitely need incompatible changes in
> > a very short time frame though, that would push towards "x-".
> > 
> > So IMHO the right answer largely depends on whether there is a credible
> > strategy to implement the ideal non-blocking solution in a reasonable amount
> > of time. I can't justify spending much time on this myself, but I'm willing
> > to consider & try proposals for solving the blocking problem if they're not
> > too complex / invasive.
> 
> Remind me, what was the problem with just making a block: migration
> channel, and then we can migrate to it?

migration only does vmstate, not disks. The current blockdev commands
are all related to external snapshots, nothing for internal snapshots
AFAIK. So we still need commands to load/save internal snapshots of
the disk data in the qcow2 files.

So we could look at loadvm/savevm conceptually as a syntax sugar above
a migration transport that targets disk images, and blockdev QMP command
that can do internal snapshots. Neither of these exist though and feel
like a significantly larger amount of work than using existing functionality
that is currently working.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|