Cinder

c-vol should always format encrypted volumes during creation

Bug #1739442 reported by Lee Yarwood
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
New
Medium
Eric Harney

Bug Description

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

Tags: luks nfs nova
Revision history for this message
Sean McGinnis (sean-mcginnis) wrote :

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.

Revision history for this message
Lee Yarwood (lyarwood) wrote :

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?

Revision history for this message
Lee Yarwood (lyarwood) wrote :

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.

Eric Harney (eharney)
Changed in cinder:
assignee: nobody → Eric Harney (eharney)
Revision history for this message
Sofia Enriquez (lsofia-enriquez) wrote :

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

Changed in cinder:
importance: Undecided → Medium
tags: added: luks nfs nova
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.