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.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|