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

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



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


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