On Sat, Apr 16, 2016 at 10:17:45AM -0400, John Ferlan wrote:
> +/* qemuDomainSecretInfoGetAlias:
> + * @secinfo: pointer to the secret info object
> + * @qemuCaps: pointer to the emulator capabilities
> + *
> + * If the emulator supports it, secinfo is available and associated with
> + * an IV secret, then return the alias created during the disk or hostdev
> + * prepare step.
> + *
> + * Returns pointer to the object alias string or NULL if not found/supported
> + */
> +const char *
> +qemuDomainSecretInfoGetAlias(qemuDomainSecretInfoPtr secinfo,
> + virQEMUCapsPtr qemuCaps)
> +{
> + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_SECRET)) {
> + VIR_INFO("secret object is not supported by this QEMU binary");
> + return NULL;
> + }
This check is not necessary - if QEMU does not support OBJECT_SECRET,
we did not generate SECRET_INFO_IV in the first place.
> @@ -941,9 +1103,23 @@ qemuDomainSecretDiskPrepare(virConnectPtr conn,
> if (VIR_ALLOC(secinfo) < 0)
> return -1;
>
> - if (qemuDomainSecretPlainSetup(conn, secinfo, src->protocol,
> - src->auth) < 0)
> - goto error;
> + /* If we have the encryption API present and can support a
> + * secret object, then build the IV secret - this is the magic
> + * decision point for utilizing the IV secrets for a disk
> + * whether it's an iSCSI or an RBD disk.
> + */
> + if (qemuDomainSecretHaveEncrypt() &&
> + virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_OBJECT_SECRET)) {
This code is shared with HostdevPrepare and could be separated to
another function.
Jan
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list