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

On Tue, Sep 01, 2020 at 04:36:59PM +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(a)redhat.com&gt; > --- > docs/manpages/virsh.rst | 15 +++- > docs/migration.html.in | 33 ++++++++ > src/qemu/qemu_migration.c | 138 +++++++++++++++++++++++-------- > src/qemu/qemu_migration_params.c | 9 ++ > src/qemu/qemu_migration_params.h | 3 + > src/qemu/qemu_monitor.c | 15 ++++ > src/qemu/qemu_monitor.h | 4 + > 7 files changed, 179 insertions(+), 38 deletions(-) > > diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst > index 4d66019e750b..e3aeaa5c44ea 100644 > --- a/docs/manpages/virsh.rst > +++ b/docs/manpages/virsh.rst > @@ -3242,7 +3242,7 @@ with the qemu driver you could use this: > > .. code-block:: > > - qemu+unix://?socket=/path/to/socket > + qemu+unix:///system?socket=/path/to/socket > > When *migrateuri* is not specified, libvirt will automatically determine the > hypervisor specific URI. Some hypervisors, including QEMU, have an optional > @@ -3270,6 +3270,14 @@ There are a few scenarios where specifying *migrateuri* may help: > might be specified to choose a specific port number outside the default range in > order to comply with local firewall policies. > > +* The *desturi* uses UNIX transport method. In this advanced case libvirt > + should not guess a *migrateuri* and it should be specified using > + UNIX socket path URI: > + > +.. code-block:: > + > + unix:///path/to/socket > + > See `https://libvirt.org/migration.html#uris <https://libvirt.org/migration.html#uris>`_ for more details on > migration URIs. > > @@ -3296,7 +3304,10 @@ specific parameters separated by '&'. Currently recognized parameters are > Optional *listen-address* sets the listen address that hypervisor on the > destination side should bind to for incoming migration. Both IPv4 and IPv6 > addresses are accepted as well as hostnames (the resolving is done on > -destination). Some hypervisors do not support this feature and will return an > +destination). In niche scenarios you can also use UNIX socket to make the > +hypervisor connection over UNIX socket in which case you must make sure the > +source can connect to the destination using the socket path provided by you. > +Some hypervisors do not support specifying the listen address and will return an > error if this parameter is used.

> Optional *disks-port* sets the port that hypervisor on destination side should > diff --git a/docs/migration.html.in b/docs/migration.html.in > index e95ee9de6f1b..8585dcab6863 100644 > --- a/docs/migration.html.in > +++ b/docs/migration.html.in > @@ -201,6 +201,9 @@ > numbers. In the latter case the management application may wish > to choose a specific port number outside the default range in order > to comply with local firewall policies.</li> > + <li>The second URI uses UNIX transport method. In this advanced case > + libvirt should not guess a *migrateuri* and it should be specified using > + UNIX socket path URI: <code>unix:///path/to/socket</code>.</li> > </ol> > > <h2><a id="config">Configuration file handling</a></h2> > @@ -628,5 +631,35 @@ virsh migrate --p2p --tunnelled web1 qemu+ssh://desthost/system qemu+ssh://10.0. > Supported by QEMU driver > </p> > > + > + <h3><a id="scenariounixsocket">Migration using only UNIX sockets</a></h3> > + > + <p> > + In niche scenarios where libvirt daemon does not have access to the > + network (e.g. running in a restricted container on a host that has > + accessible network), when a management application wants to have complete > + control over the transfer or when migrating between two containers on the > + same host all the communication can be done using UNIX sockets. This > + includes connecting to non-standard socket path for the destination > + daemon, using UNIX sockets for hypervisor's communication or for the NBD > + data transfer. All of that can be used with both peer2peer and direct > + migration options. > + </p> > + > + <p> > + Example using <code>/tmp/migdir</code> as a directory representing the > + same path visible from both libvirt daemons. That can be achieved by > + bind-mounting the same directory to different containers running separate > + daemons or forwarding connections to these sockets manually > + (using <code>socat</code>, <code>netcat</code> or a custom piece of > + software): > + <pre> > +virsh migrate web1 [--p2p] --copy-storage-all 'qemu+unix:///system?socket=/tmp/migdir/test-sock-driver' 'unix:///tmp/migdir/test-sock-qemu' [--listen-address /tmp/migdir/test-sock-qemu] --disks-uri unix:///tmp/migdir/test-sock-nbd Shoudn't the --listen-address arg be the same URI as the previous arg ?

Did we need a separate listen address parameter for disks too ?

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