On 10/04/2011 07:48 AM, Jiri Denemark wrote:
IIUC, you are trying to fix this, by making sure that the 'Finish'
method encodes the original name in the cookie, not the new name ?
Yes, although the complete picture is that incoming (from the POV of
destination libvirtd) cookie is checked against the original name instead of
the new one and cookies generated by destination libvirtd contain the original
name. It applies to Prepare as well as Finish.
ACK, if my two questions here are correct
Mostly correct so I take it as ACK :-)
Quick questions (from a latecomer to the thread): what happens if I use
both the @dname and @dxml arguments? Are we properly requiring that the
new name in both arguments match, and rejecting the migration as
impossible otherwise (since you can't request two different names), or
are we having one of the two names take priority over the other?
Also, if @dname is NULL but @dxml is provided, I think that we currently
refuse migration to a server that only understands v2 migration (since
only v3 can take @dxml). Can @dxml in isolation be used to change the
name, without the use of @dname?
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
