Booting encrypted volume with whole image fails

[Dane Fichter]

When booting from an encrypted volume created from a whole image (i.e. not a three-part image), Nova reports that the instance has booted successfully. However, simply examining the console or attempting to ssh into the instance reveals that it failed to boot.

Expected Behavior:
1. We should be able to boot from an encrypted volume containing a whole part image.
2. If booting from this volume fails, Nova should throw an error and alert the end user.

Actual Behavior:
1. Instance does not successfully boot from volume.
2. Nova provides no indication that booting has failed.

How to Reproduce behavior:
1. Download a whole image (I'm using cirros-0.3.3-x86_64.raw)
2. Add the image to Glance using the CLI:
glance image-create --name='cirros' --container-format=bare --owner=demo --disk-format=raw --is_public=true --file=cirros-0.3.3-x86_64.raw
3. Log into Horizon as an admin and create an encrypted volume type through the UI. The encrypted volume type I've been using has the following attributes:
Provider = nova.volume.encryptors.luks.LuksEncryptor
Control Location = front-end
Cipher = aes-xts-plain64
Key Size: = 512
4. Log into Horizon as demo and use the UI to create a volume of the encrypted type from the whole image. Ensure that the volume is larger than the image.
5. Use the Horizon UI to boot an instance from the encrypted volume. Be sure to select a flavor with greater disk space than the size of the image (I use m1.tiny).

You should observe that, although there are no errors presented to the end user, the instance clearly does not boot. Additionally, be way of a control, you can repeat these steps without creating an encrypted volume type and observe that the instance boots successfully.

[Markus Zoeller (markus_z) (mzoeller)]

@Dane Fichter (dane-fichter):

Since you are set as assignee, I switch the status to "In Progress".

[Joel Coffman (joel-coffman)]

From the console:

  Booting from Hard Disk...
  Boot failed: not a bootable disk

  No bootable device.

A sensible error message from Nova would be appreciated.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/203784

[Eli Qiao (taget-9)]

hi , but I don't get an error when boot from an encrypted volume on nova master commit af84e3dea346e706b3361d296c41161cc70d8d9e

I follow this guide to create encrypted type.
http://docs.openstack.org/juno/config-reference/content/section_create-encrypted-volume-type.html

taget@taget-ThinkStation-P300:/opt/stack/nova$ cinder encryption-type-list
+--------------------------------------+-------------------------------------------+-----------------+----------+------------------+
| Volume Type ID | Provider | Cipher | Key Size | Control Location |
+--------------------------------------+-------------------------------------------+-----------------+----------+------------------+
| 6ac309d3-5456-4270-9564-ae302f107290 | nova.volume.encryptors.luks.LuksEncryptor | aes-xts-plain64 | 512 | front-end |
+--------------------------------------+-------------------------------------------+-----------------+----------+------------------+

taget@taget-ThinkStation-P300:/opt/stack/nova$ cinder type-list
+--------------------------------------+-------------+-------------+-----------+
| ID | Name | Description | Is_Public |
+--------------------------------------+-------------+-------------+-----------+
| 1f7586c5-2aa8-4621-9bea-fbcbcbe89fa3 | lvmdriver-1 | - | True |
| 6ac309d3-5456-4270-9564-ae302f107290 | LUKS | - | True |
+--------------------------------------+-------------+-------------+-----------+

taget@taget-ThinkStation-P300:~$ cinder list
+--------------------------------------+-----------+-------------------------------+------+-------------+----------+-------------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Multiattach | Attached to |
+--------------------------------------+-----------+-------------------------------+------+-------------+----------+-------------+-------------+
| 20a3793c-906e-4b57-a54a-a8609edb0f53 | available | cirros-0.3.4-x86_64-uec-lucks | 5 | LUKS | true | False | |
| 46094a91-98cd-49dc-a4fe-b20cb9dcaf46 | available | encrypted volume | 1 | LUKS | false | False | |
| 8855d314-a16a-4be1-b943-f02c54e1a84d | available | unencrypted volume | 1 | lvmdriver-1 | false | False | |
+--------------------------------------+-----------+-------------------------------+------+-------------+----------+-------------+-------------+

then create an instance from 20a3793c-906e-4b57-a54a-a8609edb0f53

with this nova boot --boot-volume 20a3793c-906e-4b57-a54a-a8609edb0f53 --nic net-id=e1d6382e-0e01-4172-9772-19d83058f8f3 --flavor 2 test-volume

and I can see that vm can boot up without errors, did I miss something?

hi Joel, can you try my steps from nova command line to reproduce this issue?

Eli.

[Eli Qiao (taget-9)]

oh.. my bad, I can reproduce by ubuntu cloud image but not by cirros image, I guess that maybe due to cirros image hase kernel and initrd

[Lisa Li (lisali)]

One of the cause is that when cinder creates a encrypted volume from an image, it just reads the unencrypted data from image, and write it to the volume without encryption.
I opened a bp:
https://blueprints.launchpad.net/cinder/+spec/encrypt-volume-with-image

[OpenStack Infra (hudson-openstack)]

Change abandoned by dane-fichter (<email address hidden>) on branch: master
Review: https://review.openstack.org/203784
Reason: I am in agreement with the Cinder folks with regard to doing the fix in Cinder. And seeing as a patch more or less equivalent to mine has already been merged in Cinder, this change is no longer useful.

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/cinder 9.0.0.0b3 development milestone.