On Wed, Aug 26, 2015 at 10:19:43AM +0300, Nikolay Shirokovskiy wrote: > > > On 25.08.2015 20:28, Dmitry Guryanov wrote: > > On 08/25/2015 07:18 PM, Daniel P. Berrange wrote: > >> On Tue, Aug 25, 2015 at 12:04:14PM +0300, nshirokovskiy@xxxxxxxxxxxxx wrote: > >>> From: Nikolay Shirokovskiy <nshirokovskiy@xxxxxxxxxxxxx> > >>> > >>> This patch makes basic vz migration possible. For example by virsh: > >>> virsh -c vz:///system migrate --direct $NAME $STUB vz+ssh://$DST/system > >>> > >>> $STUB could be anything as it is required virsh argument but it is not > >>> used in direct migration. > >>> > >>> Vz migration is implemented as direct migration. The reason is that vz sdk do > >>> all the job. Prepare phase function is used to pass session uuid from > >>> destination to source so we don't introduce new rpc call. > >> I'm trying to understand why you need $STUB as dummy data. > >> > >> IIRC, when doing direct migration, you should be providing a valid > >> URI for the first parameter, and not need the second uri. > > > > virsh uses virDomainMigrateToURI3 function, and for some reason it differs > > destination URI for direct and peer-to-peer migrations. For p2p it uses > > pconnuri argument and for direct -VIR_MIGRATE_PARAM_URI <http://libvirt.org/html/libvirt-libvirt-domain.html#VIR_MIGRATE_PARAM_URI> from typed params list. > > > AFAIU in virDomainMigrateToURI3 function, dconnuri argument is treated as URI to destination libvirt daemon. > As direct migration doesn't need this kind of connection this argument is ignored. > > However as suggested vz migration implementation uses connection to destination libvirtd daemon > to get destination hypervisor session uuid I should probably use dconnuri for for that purporse > not hypervisor URI. This is related what Dmitry mentioned in previous letters where there > was a confusion between hypervisor and remote access to daemon ports. > > This would break a invariant mentioned in the documentation that direct migration > does not use dconnuri. Probably it is not too bad too get away from this restriction. Before you change the code yet again, I'll take a closer look at the migration code and try to figure out a clear correct answer. This bit of libvirt is so confusing it is easy to get wrong.... 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list