Implement support for LUKS inside qcow2 volumes when using Libvirt

This is the spec for Implement support for LUKS inside qcow2 volumes
when using Libvirt.

bp nfs-encryption-support

Change-Id: Ia7f5bbeded2ac52e0ae95e7b3f586811870e2e2f

specs/2023.2/approved/libvirt-luks-inside-qcow2-support.rst

@@ -0,0 +1,168 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+=============================================================================
+Implement support for LUKS inside qcow2 volumes when using Libvirt
+=============================================================================
+
+https://blueprints.launchpad.net/nova/+spec/nfs-encryption-support
+
+Volume encryption helps provide basic data protection in case the volume
+back-end is compromised or stolen. The contents of an encrypted volume can
+only be read with the use of a specific key.
+
+Cinder is implementing encryption on their NFS driver. Currently, the NFS
+driver uses qcow2 type volumes. As a result, those qcow2 volumes will be
+encrypted with LUKS while retaining the possibility of taking a snapshot with
+qcow2.
+
+
+Problem description
+===================
+
+Since I896f70d204ad103e968ab242ba9045ca984827c4, Cinder supports NFS
+encryption. However, attaching or booting from an NFS encrypted volume fails
+with the error `QEMU: The image is not in qcow2 format`. This happens because
+`is_luks()` returns false when LUKS is inside qcow2. Therefore, Nova formats
+the volume to native LUKS.
+
+Currently, Nova cannot handle LUKS inside qcow2 disk format.
+
+
+Use Cases
+---------
+
+- A user wants to attach an encrypted NFS volume to a Nova instance.
+- A user wants to boot an instance from an encrypted NFS volume.
+- A user wants to create a live snapshot of the attached volume.
+
+
+Proposed change
+===============
+
+First, implement a new function called is_luks_inside_qcow2 to avoid
+formatting the volume to native LUKS.
+Second, implement encryption on backingStore. The qcow2 format allows users
+to create an overlay on top of an existing image, which will be the target of
+the new guest writes. Disk image chains can be partially or fully configured
+in the domain XML. The basic approach is to use the <backingStore> elements
+in the configuration. Detection of the backing chain requires libvirt to read
+and understand the backing file field recorded in the image metadata and also
+be able to recurse and read the backing file. Due to security implications,
+libvirt will refuse to use backing images of any image whose format was not
+specified explicitly in the XML or the overlay image itself.
+
+
+Alternatives
+------------
+
+WIP
+
+
+REST API impact
+---------------
+
+None
+
+
+Data model impact
+-----------------
+
+None
+
+
+Security impact
+---------------
+
+None
+
+
+Notifications impact
+--------------------
+
+None
+
+
+Other end user impact
+---------------------
+
+None
+
+
+Performance Impact
+------------------
+
+None
+
+
+Other deployer impact
+---------------------
+
+None
+
+Developer impact
+----------------
+
+None
+
+Upgrade impact
+--------------
+
+Yes, i would be. WIP
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+  Sofia Enriquez (enriquetaso)
+
+
+Feature Liaison
+---------------
+
+
+Work Items
+----------
+
+- Implement is_luks_inside_qcow2 function:
+https://review.opendev.org/c/openstack/nova/+/854030
+- Implement encryption on backingStore:
+https://review.opendev.org/c/openstack/nova/+/870012
+
+Dependencies
+============
+
+None
+
+Testing
+=======
+
+WIP
+
+Documentation Impact
+====================
+
+None
+
+References
+==========
+
+- Nova weekly meeting discussion:
+https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2023-05-02.log.html#t2023-05-02T16:28:11
+
+History
+=======
+
+.. list-table:: Revisions
+   :header-rows: 1
+
+   * - Release Name
+     - Description
+   * - Bobcat
+     - Introduced