From nobody Mon Feb 9 06:00:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1489775986813968.5332956748018; Fri, 17 Mar 2017 11:39:46 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 57F43804E2; Fri, 17 Mar 2017 18:39:46 +0000 (UTC) Received: from colo-mx.corp.redhat.com (unknown [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2BD5FBFA6E; Fri, 17 Mar 2017 18:39:46 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id D8FFBB3484; Fri, 17 Mar 2017 18:39:45 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id v2HIdAgA025211 for ; Fri, 17 Mar 2017 14:39:10 -0400 Received: by smtp.corp.redhat.com (Postfix) id 4C6F6BFA6B; Fri, 17 Mar 2017 18:39:10 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-116-76.phx2.redhat.com [10.3.116.76]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0A213BFA67 for ; Fri, 17 Mar 2017 18:39:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 57F43804E2 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=libvir-list-bounces@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 57F43804E2 From: John Ferlan To: libvir-list@redhat.com Date: Fri, 17 Mar 2017 14:39:01 -0400 Message-Id: <20170317183901.5267-8-jferlan@redhat.com> In-Reply-To: <20170317183901.5267-1-jferlan@redhat.com> References: <20170317183901.5267-1-jferlan@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v3 7/7] qemu: Set up the migration TLS objects for source X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 17 Mar 2017 18:39:47 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" https://bugzilla.redhat.com/show_bug.cgi?id=3D1300769 If the migration flags indicate this migration will be using TLS, then while we have connection in the Begin phase check and setup the TLS environment that will be used by virMigrationRun during the Perform phase for the source to configure TLS. This creates at least an "-object tls-creds-x509,endpoint=3Dclient,..." and potentially an "-object secret,..." to handle the passphrase response to access the TLS credentials. The alias/id used for the TLS objects will contain "libvirt_migrate" as a mechanism to signify that libvirt started the migration on the source (reaping benefits possibly). Once the objects are created, the code will set the "tls-creds" and "tls-hostname" migration parameters to signify usage of TLS. Since qemuProcessRecoverMigrationOut will cancel outgoing migrations that are still in the QEMU_MIGRATION_PHASE_PERFORM{2|3} stages, there's no need to do anything special as the Perform cleanup and Cancel phases will reset the environment. Signed-off-by: John Ferlan --- src/qemu/qemu_migration.c | 53 +++++++++++++++++++++++++++++++++++++++++++= ++++ 1 file changed, 53 insertions(+) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 42074f0..5acae6e 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -3453,6 +3453,7 @@ qemuMigrationBegin(virConnectPtr conn, unsigned long flags) { virQEMUDriverPtr driver =3D conn->privateData; + virQEMUDriverConfigPtr cfg =3D NULL; char *xml =3D NULL; qemuDomainAsyncJob asyncJob; =20 @@ -3486,6 +3487,12 @@ qemuMigrationBegin(virConnectPtr conn, nmigrate_disks, migrate_disks, fla= gs))) goto endjob; =20 + if (flags & VIR_MIGRATE_TLS) { + cfg =3D virQEMUDriverGetConfig(driver); + if (qemuMigrationCheckSetupTLS(conn, driver, cfg, vm, asyncJob) < = 0) + goto endjob; + } + if ((flags & VIR_MIGRATE_CHANGE_PROTECTION)) { /* We keep the job active across API calls until the confirm() cal= l. * This prevents any other APIs being invoked while migration is t= aking @@ -3502,6 +3509,7 @@ qemuMigrationBegin(virConnectPtr conn, } =20 cleanup: + virObjectUnref(cfg); virDomainObjEndAPI(&vm); return xml; =20 @@ -5010,8 +5018,11 @@ qemuMigrationRun(virQEMUDriverPtr driver, { int ret =3D -1; unsigned int migrate_flags =3D QEMU_MONITOR_MIGRATE_BACKGROUND; + virQEMUDriverConfigPtr cfg =3D NULL; qemuDomainObjPrivatePtr priv =3D vm->privateData; qemuMigrationCookiePtr mig =3D NULL; + char *tlsAlias =3D NULL; + char *secAlias =3D NULL; qemuMigrationIOThreadPtr iothread =3D NULL; int fd =3D -1; unsigned long migrate_speed =3D resource ? resource : priv->migMaxBand= width; @@ -5075,6 +5086,38 @@ qemuMigrationRun(virQEMUDriverPtr driver, if (qemuDomainMigrateGraphicsRelocate(driver, vm, mig, graphicsuri) < = 0) VIR_WARN("unable to provide data for graphics client relocation"); =20 + if (flags & VIR_MIGRATE_TLS) { + cfg =3D 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). */ + if (spec->destType =3D=3D MIGRATION_DEST_CONNECT_HOST || + spec->destType =3D=3D MIGRATION_DEST_FD) { + if (VIR_STRDUP(migParams->migrateTLSHostname, + spec->dest.host.name) < 0) + goto cleanup; + } else { + /* Be sure there's nothing from a previous migration */ + if (VIR_STRDUP(migParams->migrateTLSHostname, "") < 0) + goto cleanup; + } + } else { + /* If we support setting the tls-creds, be sure to always reset + * the migration parameters when this migration isn't using TLS */ + if ((qemuMigrationCheckTLSCreds(driver, vm, + QEMU_ASYNC_JOB_MIGRATION_OUT) < 0)= || + (qemuMigrationSetEmptyTLSParams(priv, migParams) < 0)) + goto cleanup; + } + if (migrate_flags & (QEMU_MONITOR_MIGRATE_NON_SHARED_DISK | QEMU_MONITOR_MIGRATE_NON_SHARED_INC)) { if (mig->nbd) { @@ -5255,6 +5298,14 @@ qemuMigrationRun(virQEMUDriverPtr driver, ret =3D -1; } =20 + if (qemuMigrationDeconstructTLS(driver, vm, QEMU_ASYNC_JOB_MIGRATION_O= UT, + tlsAlias, secAlias) < 0) + ret =3D -1; + + VIR_FREE(tlsAlias); + VIR_FREE(secAlias); + virObjectUnref(cfg); + if (spec->fwdType !=3D MIGRATION_FWD_DIRECT) { if (iothread && qemuMigrationStopTunnel(iothread, ret < 0) < 0) ret =3D -1; @@ -6958,6 +7009,8 @@ qemuMigrationCancel(virQEMUDriverPtr driver, if (qemuDomainObjExitMonitor(driver, vm) < 0 || (storage && !blockJobs= )) goto endsyncjob; =20 + ignore_value(qemuMigrationResetTLS(driver, vm, QEMU_ASYNC_JOB_NONE)); + if (!storage) { ret =3D 0; goto cleanup; --=20 2.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list