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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list