[libvirt] [PATCH 0/6] Post-copy live migration support

[Dr. David Alan Gilbert]

* Eric Blake (eblake at redhat.com) wrote:
> On 09/24/2014 02:09 PM, Dr. David Alan Gilbert wrote:
> 
> >> This right here is a problem.  Qemu has explicitly documented that
> >> anything beginning with x- may be subject to change or going away in a
> >> later release, so libvirt policy has been to delay any patches
> >> targetting an x- interface until upstream qemu renames it to drop the x-
> >> to signify that it is now stable.  So we can review your patches, but
> >> can't apply them yet.
> > 
> > It is a shame that libvirt doesn't have a similar mechanism which could
> > be used in conjunction with qemu.  My reason for currently leaving the x-
> > in place is that while I don't expect the QML side to change, it seemed
> > fair to put a new feature into QEMU without locking it down for the
> > first cut.   This seems to be normal practice in QEMU but invariably
> > means that libvirt support is delayed.
> 
> Libvirt DOES have the ability to issue raw monitor commands through
> libvirt-qemu.so, and that might be sufficient for coding up the required
> hacks.

Not really.

> Or, if the libvirt proof of concept patches here do the job, we
> can feed that back to the qemu community as proof that the feature works
> enough to lose the x- prefix right away, and commit ourselves to the
> interface.  The benefit of a proof-of-concept patch done in parallel is
> that the moment the upstream qemu feature is no longer experimental,
> libvirt can apply the patches right away, and downstream distros can
> backport those packages in situations where .so stability is not violated.

My difficulty here is that 'x-' is used to convey multiple things in qemu:
  1) That the interface is unstable
  2) That the feature is unstable and might disappear/change
  3) That the feature is new and might change internally

While we're reasonably happy with (1) and (2) I did want to be
able to indicate (3) so that the onwire migration format of
the postcopy wasn't locked in yet; however given that the x-
is primarily intended to indicate interface stability, and we seem
happy with that, I think I'll try dropping the x- and see what
qemu-devel says when I try it.

Dave

--
Dr. David Alan Gilbert / dgilbert at redhat.com / Manchester, UK