c-vol should always format encrypted volumes during creation

[Lee Yarwood]

At present encrypted volumes are only formatted when data is copied into them during creation by c-vol or by the os-brick encryptors prior to their first use by n-cpu.

The os-brick encryptors will no longer be used for LUKS encrypted volumes with the introduction of native LUKS decryption in QEMU/Libvirt/Nova [1]. As a result, c-vol should _always_ format encrypted volumes during creation ensuring even blank encrypted volumes have been formatted ahead of time.

[1] https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/libvirt-qemu-native-luks.html

[Sean McGinnis (sean-mcginnis)]

I don't think Cinder is the right place for this. Cinder provides block storage, optionally with an image written to it. It should not ever be responsible for formatting a volume.

[Lee Yarwood (lyarwood)]

Even when the volume-type is associated to an encryption-volume-type detailing the method of encryption expected to be present within the volume, at least for front-end encryption?

[Lee Yarwood (lyarwood)]

Sean, just to reiterate, the end user is still presented with a RAW block storage from the volume. Any formatting that I'm suggesting take place here is of the encryption layer around said volume that is not visible to end users. c-vol already does this when copying image data into an encrypted volume FWIW.

[Sofia Enriquez (lsofia-enriquez)]

I'm facing this issue while working with NFS encrypted volumes.
The nova code [1] formats a qcow2 volume to raw, making the instance's creation fail.

ERROR nova.compute.manager [None req-0c7bdd37-43b5-4b42-b34f-2ac732d2d34f tempest-TestVolumeBootPattern-119732072 tempest-TestVolumeBootPattern-119732072-project] [instance: 014999b2-f a06-4dc5-af55-213f544165f9] Instance failed to spawn: libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2022-08-03T14:38:41.513419Z qemu-system-x86_64: -blockdev {"node-name":"libvirt-1-format","read-only":fa lse,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","encrypt":{"format":"luks","key-secret":"libvirt-1-format-luks-secret0"},"file":"libvirt-1-storage","backing":null}: Image is not in qcow2 format
 24 Aug 03 14:38:42 enriquetaso nova-compute[197128]: ERROR nova.compute.manager [instance: 014999b2-fa06-4dc5-af55-213f544165f9] Traceback (most recent call last):

[1]: https://opendev.org/openstack/nova/src/branch/master/nova/virt/libvirt/driver.py#L2065