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

[Daniel P. Berrangé]

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.

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 :|