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@xxxxxxxxxx> --- 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-nbdShoudn'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 :|
Attachment:
signature.asc
Description: PGP signature
