Boot from volume does not boot from volume

[Dane Fichter]

Booting from volume does not actually boot from the volume; it boots from a Glance image. Perform the following steps to test this:

Using the GUI steps:
1. In the "Volumes" tab, select "Create Volume". For "Volume Source", select an image (I use CirrOS). Click "Create Volume".
2. On your host machine, open a terminal and overwrite the volume:
$ sudo dd if=/dev/zero of=dev/stack-volumes-lvmdriver-1/volume-[ID OF VOLUME] bs=10M
3. In the "Instances" tab, select "Launch Instance". For "Instance Boot Source", select "Boot from volume". Be sure to select a flavor with enough storage to support the volume (if using CirrOS, pick m1.tiny). For "Volume", select the volume you created in step 1. Click "Launch".

Using the CLI:
1. Create the volume:
cinder create --image-id $(glance image-list | grep cirros-0.3.1-x86_64-uec[^-] | cut -d '|' -f 2 | xargs echo) --name sample-volume 1
2. Overwrite the volume:
$ sudo dd if=/dev/zero of=dev/stack-volumes-lvmdriver-1/volume-[ID OF VOLUME] bs=10M
3. Boot the volume:
nova boot --flavor m1.tiny --boot-volume sample-volume instance

Expected result: The instance should not boot in either of these cases; the volumes are empty.
Actual result: The instance boots successfully in both of these cases.

Additional test to show that the instance is actually being booted from the Glance image:

Using the CLI:
1. Create the volume:
cinder create --image-id $(glance image-list | grep cirros-0.3.1-x86_64-uec[^-] | cut -d '|' -f 2 | xargs echo) --name sample-volume 1
2. Delete the Glance image:
glance image-list | grep cirros-0.3.1-x86_64-uec | cut -d '|' -f 2 | xargs glance image-delete
3. Attempt to boot the volume:
nova boot --flavor m1.tiny --boot-volume sample-volume instance

Expected result: This should succeed; we are attempting to boot from the volume.
Actual result: This fails.

[Eli Qiao (taget-9)]

hi Dane
I tested and reproduce your problem, but I this is an issue.

when build an instance with an volume , nova will fetch the volume meat from that volume.
if you create an volume from an base image. all meta will be saved in the volume in cinder.
nova will get them and set them as

| volume_image_metadata | {u'kernel_id': u'712e417f-16ec-42fb-b2cb-ef8c316d9903', u'container_format': u'ami', u'min_ram': u'0', u'ramdisk_id': u'd73b7b35-b89b-4e92-98fc-dc5a7929f214', u'disk_format': u'ami', u'image_name': u'cirros-0.3.2-x86_64-uec', u'image_id': u'93169d18-1bb2-45f7-861c-6735ef687db9', u'checksum': u'4eada48c2843d2a262c814ddc92ecf2c', u'min_disk': u'0', u'size': u'25165824'} |

and libvirt found kernel_id and ramdisk_id from glance, it can boot up without issue.

I suggest that you try using another image as base to create a boot volume, then dd it.
the result is nova can boot it up , but after you try to logging it from vnc, failed due to this is not an bootable disk.

[Dane Fichter (dane-fichter)]

Eli,

Can you explain why this is marked as incomplete? In my view, it is a bit misleading to present a 'Boot from Volume' option to the user when Openstack does not actually boot from the volume. In the case where the user is encrypting the volume, this presents a security vulnerability since the user will assume that they are booting from an encrypted volume when, in fact, they are booting from an unencrypted image from Nova's image cache.

As you correctly pointed out, there IS a way for the user to actually boot from a volume. The steps are as follows:

1. Attach a volume to an instance.
2. scp a raw image to the instance.
3. ssh into the instance, dd the image into the attached volume.
4. Terminate the instance.
5. Manually modify cinder's mysql database so that the volume is listed as bootable.
6. Boot an instance from the volume.

From my perspective, this is an unnecessarily laborious process for the user to perform anytime they want OpenStack to correctly boot from a volume.

[Joel Coffman (joel-coffman)]

Ignoring the case of encrypted volumes for the moment, I think the real question is why Nova fetches the kernel and ramdisk from Glance when booting from a volume. That seems like a bug since Nova is effectively ignoring the data in the volume.

I was able to reproduce this issue.

[Duncan Thomas (duncan-thomas)]

You need to use a single-part image from glance (rather than separate kernel/root/ramdisk images) to create the volume in order to be fully booted from it, otherwise only your root comes from the volume.

Whether this is a bug or not I'll leave to other people. There's no reliable way to turn a 3 part image into a self-contained image. Maybe create-volume-from-image should just refuse if it is a multi-part image?

[Zoltan Arnold Nagy (zoltan)]

Even simply doing a "boot from volume (creates new volume)" doesn't work.

[Lee Yarwood (lyarwood)]

I've got not idea if this was ever valid but it definitely isn't now.

$ openstack volume create --image cirros-0.5.1-x86_64-disk --size 1 test
[..]
$ openstack volume set --bootable test
$ openstack image delete cirros-0.5.1-x86_64-disk
$ openstack server create --volume test --flavor 1 --network private test
[..]
$ sudo virsh domblklist d9d4dcc7-4f9e-4e1d-a2ce-c52f201ac00a
 Target Source
--------------------
 vda /dev/sdb

$ sudo virsh console d9d4dcc7-4f9e-4e1d-a2ce-c52f201ac00a
[..]
=== cirros: current=0.5.1 uptime=4.52 ===
  ____ ____ ____
 / __/ __ ____ ____ / __ \/ __/
/ /__ / // __// __// /_/ /\ \
\___//_//_/ /_/ \____/___/
   http://cirros-cloud.net