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.