On Tue, Aug 25, 2020 at 17:12:59 +0100, Daniel P. Berrangé wrote:
On Tue, Aug 25, 2020 at 05:53:32PM +0200, Jiri Denemark wrote:
> On Tue, Aug 25, 2020 at 07:47:14 +0200, Martin Kletzander wrote:
> > - /* 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).
multi-fd is certainly desirable to support and I don't see any reason
to block that.
TLS is more problematic, at least if you are using x509 credentials then
you need to tell QEMU what hostname to use for validation. This would
require us to accept a hostname parameter in the URI giving the UNIX
socket.
We already support this generally regardless on the transport via
VIR_MIGRATE_PARAM_TLS_DESTINATION parameter.
Jirka