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