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

Wed Sep 2 09:45:50 UTC 2020

On Wed, Sep 02, 2020 at 09:12:36AM +0100, Daniel P. Berrangé wrote:
>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 at redhat.com>
>> ---
>>  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.

This hunk could be dropped.

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

No, it is a leftover from previous version, but we did not need it at all, I
think I used it for different paths to sockets on source and destination, but
that is stupid.  I'll remove the listen-address references.

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

No, although after this series it is possible for disks to be migrated using
different network path using `--disks-uri tcp://<ip_address>[:<port>]/`.

>
>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/20200902/9c627425/attachment-0001.sig>