-
Epic
-
Resolution: Unresolved
-
Major
-
None
-
None
-
Allow volumes to be retyped as encrypted
-
L
-
False
-
False
-
Not Selected
-
Committed
-
Proposed
-
To Do
-
Committed
-
rhos-storage-cinder
-
Committed
-
Undefined
-
Description of problem:
An unencrypted 40G non-RHEL based image was uploaded into Glance and from that a 40G encrypted bootable volume was created via:
openstack volume create --image myimage --size 40 --type myluks_type --bootable myimage_luks
where the volume type myluks_type was defined via:
openstack volume type create --encryption-provider nova.volume.encryptors.luks.LuksEncryptor --encryption-cipher aes-xts-plain64 --encryption-key-size 256 --encryption-control-location front-end myluks_type
Starting an instance based on the encrypted volume causes the guest boot process to fail with an error indicating that the guest could not mount its root filesystem.
However, creating and booting a volume based on the same glance image but using a non-encrypted volume works without issue.
Also, increasing the size of the encrypted volume to greater than 40G (200G was tried by the customer) also allows the instance to boot correctly from an encrypted volume.
One suspicion being explored is that by introducing the LUKS header into the encrypted volume that this is truncating the image data leaving an incomplete boot image. If that is indeed the case, then the desired outcome should be an error/exception indicating that the target volume size is too small to hold the encrypted image instead of silently failing and leaving incomplete data.
Version-Release number of selected component (if applicable):
OSP16.1
How reproducible:
- Every time
Steps to Reproduce:
1. Upload unencrypted glance image specifying the image size
2. Create encrypted volume from that image specifying the volume size equal to the image size
3. Attempt to boot the encrypted volume
Actual results:
Boot fails
Expected results:
Indicate an error condition during volume creation in step 2 if the boot volume size specified is insufficient to hold the full encrypted image.
Additional info:
I have reproduced the same issue using the latest OSP16.1 and a RHEL image and it fails to boot too so this is not specific to the customer's non-RHEL based guest image.