Hello, based on your comments, here is a proposal for a "secret management" API. Rather than add explicit accessors for attributes of secrets, and hard-code the "secrets are related to storage volumes" association in the API, the proposed uses XML to manipulate the association as well as other attributes, like it is used in other areas of libvirt. The user would allocate an ID for the secret using virSecretAllocateID(), set attributes of the secret using XML, e.g. <secret ephemeral='no' private='yes'> <volume>/var/lib/libvirt/images/mail.img</volume> <description>LUKS passphrase for the main hard drive of our mail server</description> </secret> Then, the secret value can be either generated and stored by libvirt, or supplied by the user using virSecretSetValue(). A simple API is provided for enumeration of all secrets. Very large deployments manage secret IDs automatically, so it probably is not necessary to provide specialized lookup functions (e.g. allowing the volume key -> secret ID lookup in less than O(number of secrets)). The <encryption> element used in volume and domain specifications remains, but it never contains any secrets directly, only something like <secret type='passphrase' secret_id='c1f11a6d-8c5d-4a3e-ac7a-4e171c5e0d4a' /> More detailed documentation is in the patch. Does that look OK? Thank you, Mirek