On Tue, Oct 04, 2011 at 08:48:48 -0600, Eric Blake wrote: > 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? These are actually very good questions :-) If dname is provided, it overrides the name from XML (no matter if that's from GetXMLDesc or dxml). > 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? However, if dname is not provided by dxml is and it contains domain name which is different, the destination libvirtd will have the name from dxml while source libvirtd will use the original name and migration will not work if those names do not match. But we don't currently have an explicit check for dxml name. I'm thinking about requiring the name to match either original name or dname (if set). Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list