On Wed, Mar 22, 2017 at 21:42:49 -0400, John Ferlan wrote:
> On 03/22/2017 12:26 PM, Jiri Denemark wrote:
> > On Fri, Mar 17, 2017 at 14:39:01 -0400, John Ferlan wrote:
...
> >> @@ -5075,6 +5086,38 @@ qemuMigrationRun(virQEMUDriverPtr driver,
> >> if (qemuDomainMigrateGraphicsRelocate(driver, vm, mig, graphicsuri) < 0)
> >> VIR_WARN("unable to provide data for graphics client relocation");
> >>
> >> + if (flags & VIR_MIGRATE_TLS) {
> >> + cfg = virQEMUDriverGetConfig(driver);
> >> +
> >> + /* Begin/CheckSetupTLS already set up migTLSAlias, the following
> >> + * assumes that and adds the TLS objects to the domain. */
> >> + if (qemuMigrationAddTLSObjects(driver, vm, cfg, false,
> >> + QEMU_ASYNC_JOB_MIGRATION_OUT,
> >> + &tlsAlias, &secAlias, migParams) < 0)
> >> + goto cleanup;
> >> +
> >> + /* We need to add the tls-hostname only for special circumstances,
> >> + * e.g. for a fd: or exec: based migration. As it turns out the
> >> + * CONNECT_HOST turns into an FD migration (see below). */
> >
> > Specifically, we need to add tls-hostname whenever QEMU itself does not
> > connect directly to the destination, which means
> > MIGRATION_DEST_CONNECT_HOST and MIGRATION_DEST_FD.
> >
>
> Sure - something that wasn't obvious on my first pass through the code.
> In fact having CONNECT_HOST change into FD later on wasn't as obvious to
> me until I dug through the code.
>
> I can change the comment to:
>
> /* We need to add tls-hostname whenever QEMU itself does not
> * connect directly to the destination. NB: The CONNECT_HOST
> * turns into a FD migration below in qemuMigrationConnect */
The important thing is the semantics of MIGRATION_DEST_CONNECT_HOST and
not the fact that it changes into MIGRATION_DEST_FD. I guess having the
semantics documented for each member of the qemuMigrationDestinationType
enum would help quite a bit :-) With this documentation in place, the
"NB:..." part would not be needed.
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
