[libvirt PATCH 8/9] qemu: Allow migration over UNIX socket

[Martin Kletzander]

On Wed, Aug 26, 2020 at 09:20:20AM +0100, Daniel P. Berrangé wrote:
>On Wed, Aug 26, 2020 at 12:14:44AM +0200, Martin Kletzander wrote:
>> On Tue, Aug 25, 2020 at 04:31:29PM +0100, Daniel P. Berrangé wrote:
>> > On Tue, Aug 25, 2020 at 07:47:14AM +0200, Martin Kletzander wrote:
>> > > This allows:
>> > >
>> > >  a) migration without access to network
>> > >
>> > >  b) complete control of the migration stream
>> > >
>> > >  c) easy migration between containerised libvirt daemons on the same host
>> > >
>> > > Resolves: https://bugzilla.redhat.com/1638889
>> > >
>> > > Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>> > > ---
>> > >  docs/manpages/virsh.rst   |  17 ++++-
>> > >  docs/migration.html.in    |  33 ++++++++++
>> > >  src/qemu/qemu_migration.c | 128 +++++++++++++++++++++++++++-----------
>> >
>> >
>> > > +virsh migrate web1 [--p2p] --copy-storage-all 'qemu+unix:///system?socket=/tmp/migdir/test-sock-driver' 'unix://?socket=/tmp/migdir/test-sock-qemu' [--listen-address /tmp/migdir/test-sock-qemu] --disks-socket /tmp/migdir/test-sock-nbd
>> > > +    </pre>
>> >
>> > Why  unix://?socket=/tmp/migdir/test-sock-qemu  instead of the more obvious
>> > unix:///tmp/migdir/test-sock-qemu  ?  It feels like ?socket is just
>> > reinventing the URI path component.
>> >
>> > That ?socket syntax makes sense for the libvirtd URIs, because we use
>> > the path component to identify the libvirtd instance.
>> >
>> > For the migration URI nothing is using the path component, so we should
>> > use that for the UNIX path.
>> >
>>
>> I, personally, would prefer to have it unified.  Having different way of
>> specifying a unix socket for each parameter is just anti-UX.  And since the
>> libvirt URI and NBD URI [1] might use the path component, I did not want to
>> reinvent the wheel of specifying socket paths.  And I'm not getting to anonymous
>> sockets and the like.
>
>Both the libvirt URI and NBD URI are doing multiple different jobs,encoding
>both the address of the server and a bunch of extra components. Libvirt
>choose to use the path as a "instance name" which effectively should be
>thought of as ust an alias/symlink for the socket path. IOW, libvirt should
>really not have added a "socket" parameter at all, just accepted the UNIX
>socket path as the URI path.
>
>NBD, was dealing with the fact that UNIX path had to be retrofitted after
>the URI path had alrady seen common use for the export name. If it was
>not for existing practice, export name would have been better  as a URI
>parameter IMHO
>
>In the case of the URIs we need for migration stream and NBD stream, the
>only thing we need is the address of the target. There's no compelling
>reason to avoid using the URI path in that sense. I don't find following
>the libvirt / NBD URI approach compelling because we're not following the
>rest of their URI scheme, and they are both flawed due to historical
>mistakes.
>

OK, I'll rewrite that.

>Regards,
>Daniel
>-- 
>|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
>|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
>|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200826/d8277794/attachment-0001.sig>