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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 25, 2020 at 07:47:14 +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@xxxxxxxxxx>
> ---
>  docs/manpages/virsh.rst   |  17 ++++-
>  docs/migration.html.in    |  33 ++++++++++
>  src/qemu/qemu_migration.c | 128 +++++++++++++++++++++++++++-----------
>  3 files changed, 139 insertions(+), 39 deletions(-)
> 
> diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst
> index cbb3c18deb30..82f7c9f77488 100644
> --- a/docs/manpages/virsh.rst
> +++ b/docs/manpages/virsh.rst
> @@ -3237,12 +3237,12 @@ has different semantics:
>  
>  In a special circumstance where you require a complete control of the connection
>  and/or libvirt does not have network access to the remote side you can use a
> -unix transport in the URI and specify a socket path in the query, for example
> +UNIX transport in the URI and specify a socket path in the query, for example
>  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

This hunk looks like it should go into the previous patch 7/9 (peer2peer
migration: allow connecting to local sockets).

> @@ -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://?socket=/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..9c8417674b22 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://?socket=/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 a niche scenarion where libvirt daemon does not have access to the

s/scenarion/scenario/

or

s/a // and s/scenarion/scenarios/

> +      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://?socket=/tmp/migdir/test-sock-qemu' [--listen-address /tmp/migdir/test-sock-qemu] --disks-socket /tmp/migdir/test-sock-nbd
> +    </pre>
> +
> +    <p>
> +      Supported by QEMU driver
> +    </p>
> +
>    </body>
>  </html>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index 3f4690f8fb72..1158d152869c 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
...
> @@ -3931,16 +3969,34 @@ qemuMigrationSrcPerformNative(virQEMUDriverPtr driver,
>          }
>      }
>  
> -    /* RDMA and multi-fd migration requires QEMU to connect to the destination
> -     * itself.
> -     */
> -    if (STREQ(uribits->scheme, "rdma") || (flags & VIR_MIGRATE_PARALLEL))
> -        spec.destType = MIGRATION_DEST_HOST;
> -    else
> -        spec.destType = MIGRATION_DEST_CONNECT_HOST;
> -    spec.dest.host.protocol = uribits->scheme;
> -    spec.dest.host.name = uribits->server;
> -    spec.dest.host.port = uribits->port;
> +    if (STREQ(uribits->scheme, "unix")) {
> +        if (flags & VIR_MIGRATE_TLS) {
> +            virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
> +                           _("Migration over UNIX socket with TLS is not supported"));
> +            return -1;
> +        }
> +        if (flags & VIR_MIGRATE_PARALLEL) {
> +            virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
> +                           _("Parallel migration over UNIX socket is not supported"));
> +            return -1;
> +        }

Is there a reason for not supporting TLS and multi-fd with unix sockets?
>From libvirt's POV this should be fairly trivial (can be a follow-up
patch, though): introduce MIGRATION_DEST_SOCKET in addition to
MIGRATION_DEST_CONNECT_SOCKET and use it to instruct QEMU to connect
using unix: URI (unless this support was removed from QEMU).

> +
> +        spec.destType = MIGRATION_DEST_CONNECT_SOCKET;
> +        spec.dest.socket.path = virURIGetParam(uribits, "socket");
> +    } else {
> +        /* RDMA and multi-fd migration requires QEMU to connect to the destination
> +         * itself.
> +         */
> +        if (STREQ(uribits->scheme, "rdma") || (flags & VIR_MIGRATE_PARALLEL))
> +            spec.destType = MIGRATION_DEST_HOST;
> +        else
> +            spec.destType = MIGRATION_DEST_CONNECT_HOST;
> +
> +        spec.dest.host.protocol = uribits->scheme;
> +        spec.dest.host.name = uribits->server;
> +        spec.dest.host.port = uribits->port;
> +    }
> +
>      spec.fwdType = MIGRATION_FWD_DIRECT;
>  
>      ret = qemuMigrationSrcRun(driver, vm, persist_xml, cookiein, cookieinlen, cookieout,

Reviewed-by: Jiri Denemark <jdenemar@xxxxxxxxxx>




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux