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

[Peter Krempa]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170922/7038e301/attachment-0001.sig>