Bug 1943639

+++ This bug was initially created as a clone of Bug #1936564 +++

Description of problem:

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. 

In addition, increasing the size of the encrypted volume to greater
than the images size also allows the instance to boot correctly
from an encrypted volume.

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):

13z16

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 but Cinder doesn't show errors or warnings.

When creating an encrypted RBD volume from an image, the flow is
something like:

qemu-img create <encrypted file>
qemu-img convert <image> <encrypted file>
rbd import <encrypted file>

but, the create specifies a size based on the volume size, i.e. 1024MB
for a 1GB volume.

Then the convert from raw to LUKS assumes that a 1024MB image being
converted into that file would fit into that encrypted file -- but it
doesn't fit because capacity is lost due to the LUKS headers.  qemu-img
convert here truncates data but doesn't fail when doing so.

rbd import then succeeds and the end of the image/volume is missing when
the volume is attached.

Expected results from the reporter:

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.

- CEPH RBD configuration with a CEPH 4.X storage cluster.

- Glance image is on CEPH as well.