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.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
