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