Uploaded image for project: 'Red Hat OpenStack Services on OpenShift'
  1. Red Hat OpenStack Services on OpenShift
  2. OSPRH-2950

BZ#1936564 Creating an encrypted bootable volume from an unencrypted glance image causes the resulting instance to fail to boot.

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • openstack-cinder
    • 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.

              cinder-bugs@redhat.com cinder-bugs@redhat.com
              rhn-support-marjones Mark Jones (Inactive)
              rhos-storage-cinder
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: