Issues with booting from the volume

[Vincent Hou]

Folks, correct me when I make a mistake.

Issue 1:
First, I create a bootable volume with "cinder create --image-id $image_id--display_name=boot_volume --display_description "test bootable volume" 2".
What I expect: the image has been copied into the volume.
Then, I boot a VM from this volume with "nova boot --flavor 2 --block-device-mapping vda=$vol_id --security_groups=default VM_test".
What I expect: the VM should be successfully booted and in healthy state.
Result: The VM is unable to ping.

Issue 2:
First, I create a volume with with "cinder create 2".
Then, I boot a VM from this non-bootable volume with "nova boot --flavor 2 --block-device-mapping vda=$vol_id --security_groups=default VM_test_1".
What I expect: see some warning or error message telling me that this volume is not bootable.
Result: the VM is successfully booted with no error, but it cannot be pinged.

Please advise with your comments.

[Huang Zhiteng (zhiteng-huang)]

For issue 1, have you isolated this problem from Nova issues? It could possibly be a Nova/Quantum issue instead of Cinder.

[Vincent Hou (houshengbo)]

I was using the all-in-one mode. Everything is running on one machine after I run the devstack script.
I also tried boot a VM from an image, and the VM can be accessed.

[Dermot Tynan (dtynan)]

Issue #1: any chance of a console log? Sounds like the image isn't appropriate. You could try booting a regular instance, attaching that volume to the instance and mounting it, to see if it does indeed have a file system (whatever about a partition table and a boot block).

Issue #2: there's nothing in the code to prevent you doing what you did, but whether that's a bug or a feature is another story. We (HPCS) don't allow people to create instances from volumes using the web interface, unless the volume has data in the 'volume_glance_metadata' table. You can still use the CLI to do what you did, because you may have created the volume in some other way, possibly building the partition data and boot block by hand, while attached as a non-root device to another instance.

[Vincent Hou (houshengbo)]

For Issue 1: I launch a VM, and attached a volume created from an image at /dev/vdb. Then I run sudo fdisk -l and here is the result.

======================================Result====================================================
ubuntu@vm:/tmp/stage$ sudo fdisk -l

Disk /dev/vda: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot Start End Blocks Id System
/dev/vda1 * 16065 4192964 2088450 83 Linux

Disk /dev/vdb: 1073 MB, 1073741824 bytes
16 heads, 63 sectors/track, 2080 cylinders, total 2097152 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/vdb doesn't contain a valid partition table

It seems the volume has no valid partition table and it won't be able to boot. I check the method to copy image to a volume. IMO, image_utils.fetch_to_raw for ISCSIDriver does not really create a bootable volume.

[Vincent Hou (houshengbo)]

Here is the log when I tried to boot from a volume created from an image. 694dab66-924a-456b-b81f-b32e319e54d6 is the volume id.
Sorry, there is Chinese in the log.

========================================Log og n-cpu==============================
2013-03-25 14:05:02.835 DEBUG nova.openstack.common.rpc.amqp [-] received {u'_context_roles': [u'admin'], u'_context_request_id': u'req-8845c4a1-4d3e-4b19-a8eb-6a6d023dfc71', u'_context_quota_class': None, u'_context_project_name': u'admin', u'_context_service_catalog': [{u'endpoints': [{u'adminURL': u'http://9.119.148.37:8776/v1/74a588cd2b2247ccb84a2c81c038e4a7', u'region': u'RegionOne', u'internalURL': u'http://9.119.148.37:8776/v1/74a588cd2b2247ccb84a2c81c038e4a7', u'serviceName': u'cinder', u'id': u'09ee724452d54a6dadc109f88638f6f5', u'publicURL': u'http://9.119.148.37:8776/v1/74a588cd2b2247ccb84a2c81c038e4a7'}], u'endpoints_links': [], u'type': u'volume', u'name': u'cinder'}], u'_context_user_name': u'admin', u'_context_auth_token': '<SANITIZED>', u'args': {u'node': u'vincent-ThinkPad-T410', u'request_spec': {u'block_device_mapping': [{u'volume_id': u'694dab66-924a-456b-b81f-b32e319e54d6', u'device_name': u'vda'}], u'image': {}, u'instance_type': {u'disabled': False, u'root_gb': 0, u'name': u'm1.tiny', u'flavorid': u'1', u'deleted': 0, u'created_at': None, u'ephemeral_gb': 0, u'updated_at': None, u'memory_mb': 512, u'vcpus': 1, u'extra_specs': {}, u'swap': 0, u'rxtx_factor': 1.0, u'is_public': True, u'deleted_at': None, u'vcpu_weight': None, u'id': 2}, u'instance_properties': {u'vm_state': u'building', u'availability_zone': None, u'launch_index': 0, u'ephemeral_gb': 0, u'instance_type_id': 2, u'user_data': None, u'vm_mode': None, u'reservation_id': u'r-ov9t16k2', u'config_drive_id': u'', u'root_device_name': None, u'user_id': u'c396313a5b7b4cf89ac180ee1dc918d7', u'display_description': u'VM_test', u'key_data': None, u'power_state': 0, u'progress': 0, u'project_id': u'74a588cd2b2247ccb84a2c81c038e4a7', u'config_drive': u'', u'ramdisk_id': u'', u'access_ip_v6': None, u'access_ip_v4': None, u'kernel_id': u'', u'key_name': None, u'display_name': u'VM_test', u'system_metadata': {u'instance_type_memory_mb': 512, u'instance_type_swap': 0, u'instance_type_vcpu_weight': None, u'instance_type_root_gb': 0, u'instance_type_name': u'm1.tiny', u'instance_type_id': 2, u'instance_type_ephemeral_gb': 0, u'instance_type_rxtx_factor': 1.0, u'instance_type_flavorid': u'1', u'instance_type_vcpus': 1, u'image_base_image_ref': u''}, u'root_gb': 0, u'locked': False, u'launch_time': u'2013-03-25T06:05:02Z', u'memory_mb': 512, u'vcpus': 1, u'image_ref': u'', u'architecture': None, u'auto_disk_config': None, u'os_type': None, u'metadata': {}}, u'security_group': [u'default'], u'instance_uuids': [u'61ce878b-1836-4bf7-b220-134e24aa6100']}, u'requested_networks': None, u'filter_properties': {u'config_options': {}, u'limits': {u'memory_mb': 5724.0}, u'request_spec': {u'block_device_mapping': [{u'volume_id': u'694dab66-924a-456b-b81f-b32e319e54d6', u'device_name': u'vda'}], u'image': {}, u'instance_type': {u'disabled': False, u'root_gb': 0, u'name': u'm1.tiny', u'flavorid': u'1', u'de...

[Vincent Hou (houshengbo)]

I may be wrong about the cause for Issue 1. Here is my guess:
Cinder has a table called volume_glance_metadata to maintain all the metadata copied from the glance image, but I have not found nova using these metadata when booting from the volume. An instance is unable to be without the metadata. If the image-id is specified, the metadata can be retrieved from glance. If block_deveice_mapping is specified without image-id, we need the metadata from volume_glance_metadata table to successfully boot an instance.
Need people's comments for it.

[Yatin Kumbhare (yatinkumbhare-c)]

cinder create --image-id XXX --display-name imgvol --volume-type iscsi 1

Here, cinder/api/v1/volumes.py - create() get's image id

but, i noticed that cinder/volume/manager.py - create_volume() method receives image-id as None.

Can anyone let me know code flow b/w this two above files?

[Vincent Hou (houshengbo)]

I have found the root cause for this bug.

This issue only happens to the UEC images, because one UEC image references two other images kernel and ramdisk. When we create a volume for the UEC image, only UEC itself is copied, and kernel and ramdisk images are still in glance. The good news is that kernel_id and ramdisk_id are stored in volume_glance_metadata.

There is no need to fix in cinder. It is enough to check this particular case in nova when booting from volume and find the right kernel and ramdisk images by looking up the volume_glance_metadata.

[OpenStack Infra (hudson-openstack)]

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

[Vincent Hou (houshengbo)]

This issue has been fixed by https://review.openstack.org/#/c/33296/.