----- "Daniel P. Berrange" <berrange@redhat.com> wrote:

For the domain XML I agree that libirt would not need to worry about multiple LUKS keys, but for the storage volume XML we would need to expose the fact that there are multiple keys,or allow creation of volumes with multiple keys. I don't know. Does a fact that a feature exist imply that libvirt must fully expose it? Any use case for multiple LUKS passphrases I can think of is a bit far-fetched.

...

We know that the type and amount of information that will need to be stored will vary depending on the "encryption format"; on the other hand, expecting that the information consists of independent "secrets", each with a simple and format-independent definition, is probably too optimistic. (As mentioned above, we might need a key slot ID associated with a LUKS passphrase; we might also need a password hash algorithm associated with a dm-crypt passphrase. The encryption formats used in practice are often complex enough that a "simple passphrase" can not be used.) Once we have to assume that each secret can have an "encryption format"-dependent format, I think it is much clearer to use something like

The idea of a 'key slot' and 'password hash algorithm' are not neccessarily unique to LUKS though. No, but the specific semantics and value ranges are very likely to be different across formats.

If we get 2 different encryption formats both requiring the concept of a 'key slot' we need to represent them in the same way in the XML, not hve a different XML for each format. I was arguing about making the internal representation format-specific, not the XML.

In the XML, having something like <secret type='...' id='...'> and <parameter name='...' id='...'> is quite reasonable. I think this is not the case in the internal representation - the information will eventually have to be "parsed" into format-specific variables, and it seems better to me to do this at once from the XML, than to create an additional internal representation and additionl "parsing" code. <snip>

The libvirt approach to XML representation is to try and define XML format that are indenpedant of specific implementations. This does imply that the XML parser cannot really do anything beyond basic syntactic validation, near zero semantic validation. The task of semantic validation of the parsed data, is thus passed off to the internal drivers which provide the specific implementations. Not having any driver-specific knowledge in the generic parser does make sense; I'll change the code. Mirek