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