[libvirt] [PATCH v2 11/14] qemu: Add disk secret object hash table to _qemuDomainObjPrivate

[John Ferlan]

On 09/22/2017 05:44 AM, Peter Krempa wrote:
> On Fri, Sep 15, 2017 at 20:30:14 -0400, John Ferlan wrote:
>> Currently when an AES secret object is added to the domain for
>> either a network disk, a LUKS encryption secret, or for a SCSI
>> hostdev there is no way for domain restart to be able to connect
>> or determine which secret by secrettype and uuid or usage was
>> used in order to generate the object.
>>
>> So, in order to be able to lookup which secret generated the
>> object, this patch will create and manage a private object hash
>> table that tracks when a disk using the secret object is added
>> or removed in order to be able to "rebuild" the secret.
>>
>> This information will be recorded in the domain private XML file
>> so that when libvirtd restarts, we can rebuild and determine which
>> secret was used.
>>
>> The qemuDomainObjDiskSecretObjectAliasEntryLookup helper is
>> currently unused, but it's purpose would be to find the object
>> alias in the table and return the usageType and seclookupdef
>> that created the object. Could be quite useful for something.
> 
> I don't quite see the reason to add all this code. All secret related
> stuff can be stored in the virStorageSource private data. If you need to
> format and load it, you can iterate them in the private XML formatter
> and don't need any hash table.
> 
> Additionally you should not need to be able to identify which secret was
> used once the VM is running, since we don't access it afterwards. Also
> the secret data can become stale since user may undefine the secret.
> 
> Looks like this is quite a lot of code without any real use case, thus
> I'm inclined to a NACK, if you don't provide any more supporting
> explanation.
> 

No special reason - I wasn't sure if being able to look up the secret
from an alias provided was going to be useful or not. I did discuss this
in the cover, but IIRC you don't always read those ;-).

John