On Fri, May 06, 2016 at 12:30:27PM +0100, Daniel P. Berrange wrote:
On Fri, May 06, 2016 at 01:27:15PM +0200, Pavel Hrdina wrote:
> On Thu, May 05, 2016 at 07:18:51PM -0400, John Ferlan wrote:
>
> [...]
>
> > Been sitting on list for a while ....
> >
> > Obviously I think you know you have to update to top of tree
> >
> > Would be nice to perhaps add a few intro comments to
> > qemuMigratePrepareDomain at least with respect to what the purpose is
> > and what "could" be done in the future in the code. Looks like to me
> > it's now a shim to qemuProcessPrepareDomain to take care of any of those
> > "inconsistencies" between what can be supported in/on the new system
> > (perhaps could work in the opposite direction too ;-))... When I'm
> > reading code, I'm not necessarily looking at the commit message that
> > added which may have that information.
> >
> > I think you could also update the commit message to point at the
> > previous code that was reverted to help understand the history.
> >
> > ACK for the concept - looks like things are OK to me.
> >
> > John
>
> The only issue with this patch is that it breaks migration back to older
> libvirt. We generally try to not break migration to old libvirt if you migrate
> from new libvirt to old libvirt with the same XML that would be also valid for
> the old libvirt. Since there is no change in the XML and we start using the
> 'heads' attribute and we now pass that value to qemu you cannot migrate back
to
> some older libvirt.
>
> NACK, we need to figure this out.
Yep, the major use of QXL is RHEV/oVirt and they explicitly require libvirt
to support migration to old versions. So we need to figure this out.
So I should basically revert the difference between v1 and v2 and send a
v6 with that? The discussion in v1 [1] didn't reach any conclusion so I
believe we can safely do that.
Martin
[1]
https://www.redhat.com/archives/libvir-list/2016-March/msg00418.html