Boot from volume does not boot from volume

Bug #1449084 reported by Dane Fichter on 2015-04-27
40
This bug affects 6 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Medium
Unassigned

Bug Description

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

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.

Changed in nova:
status: New → Incomplete
Dane Fichter (dane-fichter) wrote :

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

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.

Changed in nova:
status: Incomplete → Confirmed
Duncan Thomas (duncan-thomas) wrote :

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?

Matt Riedemann (mriedem) on 2015-06-16
tags: added: volumes
Matt Riedemann (mriedem) on 2015-06-16
Changed in nova:
importance: Undecided → Medium
Zoltan Arnold Nagy (zoltan) wrote :

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

Changed in nova:
assignee: nobody → Sreenivas (sreenivas-pothukanoori)
Sean Dague (sdague) on 2017-06-23
Changed in nova:
assignee: Sreenivas (sreenivas-pothukanoori) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers