On 06/21/2016 08:20 AM, Peter Krempa wrote:
On Mon, Jun 13, 2016 at 20:27:51 -0400, John Ferlan wrote:
> Currently the assumption is there is one type of disk encryption - in
> some qcow format which is old and crusty... But there's a new sheriff
> in town known as 'luks' and we'll need to handle that shortly
>
> Signed-off-by: John Ferlan <jferlan(a)redhat.com>
> ---
> src/util/virstoragefile.c | 54 ++++++++++++++++++++++++++++-------------------
> 1 file changed, 32 insertions(+), 22 deletions(-)
>
> diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
> index 6d7e5d9..5c2519c 100644
> --- a/src/util/virstoragefile.c
> +++ b/src/util/virstoragefile.c
[...]
> @@ -111,6 +111,11 @@ enum {
> BACKING_STORE_ERROR,
> };
>
> +enum fi_crypt {
> + FI_CRYPT_NONE = 0,
> + FI_CRYPT_QCOW
This lacks the "VIR_" prefix. Also I don't really see a point in adding
this. Currently it's used to distinguish between an encrypted QCOW and
an unencrypted QCOW. With LUKS (as you note later in a comment) it's
implied that they are encrypted and thus we don't need a side band to
store the same data.
OK I can drop this... It would be replaced in "a" subsequent patch with
a more direct "meta->format == VIR_STORAGE_FILE_LUKS" type check in
order to allocate meta->encryption
John