On 08.01.2016 02:30, Jiri Denemark wrote: > On Wed, Nov 18, 2015 at 20:12:58 +0200, Pavel Boldin wrote: >> The provided patchset implements NBD disk migration over a tunnelled >> connection provided by libvirt. >> >> The migration source instructs QEMU to NBD mirror drives into the provided >> UNIX socket. These connections and all the data are then tunnelled to the >> destination using newly introduced RPC call. The migration destination >> implements a driver method that connects the tunnelled stream to the QEMU's >> NBD destination. > > To be honest, I'm still in doubts this is all worth the effort. This > code will likely be unused once both QEMU and libvirt gain proper TLS > support for migration. The current tunneled migration is known to be > slow due to the big overhead and even with the presence of a better > alternative we'd still have to maintain this code. Not to mention that > it increases the (already great) complexity of our migration code and > adds another dimension to a testing matrix. > > Jirka Hi. Here in virtuozzo we need to support encrypted migration in near future and want to be able to pass all migration traffic thru single socket too. So we upvote this patch if it matters. If technical implications are so high could we elaborate another approach to organize single socket encrypted migration? There is an RFC already - https://www.redhat.com/archives/libvir-list/2015-November/msg00294.html. However because it is probably too short and Jan's comments gives some hints too I'll rephrase it here. It is perfectly possible to organize external migration tunnel with current options. We can set migration uri to "127.0.0.1:port" and use VIR_MIGRATE_PARAM_LISTEN_ADDRESS equal to "127.0.0.1". This set of options would cause source qemu to migrate to "127.0.0.1:port" and destination qemu to handle migration on "127.0.0.1:port". Thus we can tunnel by forwarding "port" from source to destination. However if VM has non shared disks we can't do it. The problem is that port for disks migration will be choosen by destination side automatiacally and we have no possibility to organize an appropriate port forwarding beforehand. So the proposition is to add one more option, say VIR_MIGRATE_PARAM_NBD_PORT so that nbd port could be specified in migration command. This should not add much complexity. > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list