On 05/02/2016 09:47 AM, Ján Tomko wrote: > 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. >
OK probably a remnant of over checking things. >> @@ -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. > Well more or less, but I'll make it work. Tks - John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list