On Wed, Sep 02, 2020 at 11:53:37 +0200, Jiri Denemark wrote: > On Tue, Sep 01, 2020 at 16:36:59 +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 > > Ah, again I didn't notice the incorrect URI until I saw this patch... > This hunk should go into the previous patch. > > > @@ -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 > > The listen address is a bit strange. With TCP this is the IP address > QEMU on the destination host will be listening for incoming migration. > But do we need this at all for UNIX sockets? I think coming up with a > socket path which would be available on both hosts shouldn't be too > hard. Ability to use different sockets on each side would provide > greater flexibility, but I'm not sure it's worth the effort. Since > normally listen address is just an IP address, using socket path here > seems to be OK as it is the address of a UNIX socket, but it looks > confusing. I don't think forcing unix:///socket/path as the listen > address would make things significantly better. And creating a new > listen URI parameter doesn't sound like a good idea either. > > That said, I would either drop support for UNIX sockets in listen > address or keep it the way you implemented it. If you decide to keep it, > proper documented would be appreciated. Mentioning it only as an > optional (and redundant in this case) argument in the example doesn't > seem optimal at all. > > And after reading the rest of the patch, I can see we gained the support > for socket path in listen address for free. Forbidding it would require > an explicit check for a valid listen IP address. So I think we could > just enhance the documentation of the listen address to mention UNIX > sockets and keep it supported. So let me correct myself. I missed the line which overrides any listenAddress passed via a parameter with the path from unix:// URI. I guess you can report an error at that point. And of course, drop the --listen-address usage from the example. Jirka
