Hi @agrare,

I would like to know if there are any updates on this issue. Please let me know if further information is needed from my side.

Thank you!

Hi @agrare,

By using OpenStack's "Create New Volume" option, the volume is added under /vda.

However, when trying to add a volume using ManageIQ while provisioning an instance, the volume is added under /vdb.

We need to ensure that the volume is added under /vda while provisioning instance from ManageIQ as well. Please guide us on how to do that. Refer to the attached images where the volume is added using both OpenStack and ManageIQ.

1. Openstack (10GB is added under /vda):
   

2. ManageIQ (10GB is added under /vdb):
   

Hi @Fryguy and @GilbertCherrie, Do you have any insights on this?

Hey @Dhamo1107 sorry no I haven't gotten a chance to look at this yet.
So when we create a new volume that is done here https://github.com/ManageIQ/manageiq-providers-openstack/blob/master/app/models/manageiq/providers/openstack/cloud_manager/provision/volume_attachment.rb

I'm not as well versed with the openstack API as you likely are, if you can post what properties would have to be provided to make a disk a "root" volume we can update our volume_attachment code to check for that attribute and set it appropriately.

Hi @agrare,

Thank you for your insights.

This is the OpenStack documentation on how to Create volume from image and boot instance. From the document, I believe the parameters likely to be sent from ManageIQ to OpenStack to create that volume in vda are --block-device and boot_index: 0. I added new_volume_attrs[:boot_index] = 0 this in volume_attachment.rb file. However, I received the error message: Block Device Mapping is Invalid: Boot sequence for the instance and image/block device mapping combination is not valid.

@Dhamo1107 I think the issue is that we have a "default" first volume.

https://github.com/ManageIQ/manageiq-providers-openstack/blob/master/app/models/manageiq/providers/openstack/cloud_manager/provision/volume_attachment.rb#L3 that is the "first" disk and you can see the default volume has :boot_index => 0 https://github.com/ManageIQ/manageiq-providers-openstack/blob/master/app/models/manageiq/providers/openstack/cloud_manager/provision/volume_attachment.rb#L39-L49 so I think the issue that you're hitting is you have two volumes with boot_index=0

What I think we need is to check if the source has a root_disk (maybe root_disk_size == 0 ? Can you check that?) and if it doesn't then we shouldn't have a default_volume.

volumes_attrs_list = []
volumes_attrs_list << default_volume_attributes if instance_type.root_disk_size > 0

Then in your requested_volumes the first volume that you want to create as a boot disk you would set :boot_index => 0

Hi @agrare,

Thank you for your insights; they helped us successfully create a volume under vda.

I have updated my volume_attachment.rb file as shown below:

volumes_attrs_list = []
volumes_attrs_list << default_volume_attributes if instance_type.root_disk_size > 0

The volume is now attached under vda successfully:

However, when I check the console of the provisioned instance, I still encounter the No bootable device error:

I tried setting new_volume_attrs[:bootable] = true inside the requested_volumes.each do |volume_attrs| block, but it did not resolve the issue. The bootable spec in the volume section of the created volume still shows "NO."

Could you share your thoughts on how to make the volume bootable? Thank you!

Hi @agrare, we are encountering an issue where the volume is created under vda, but there is no bootable device. The issue seems to be because the volume is created without an OS image, which is likely causing the error. In the attached image of the volume_attachment.rb file:

in the requested_volumes block, I initially set the uuid as new_volume_id, the source_type as volume, and the destination_type as volume. However, I think the correct source_type should be the image, along with its UUID as source.ems_ref, and the destination_type should be volume. I’ve now made that change.

However, I’m now getting this error: Images with destination_type volume need to have a non-zero size specified.

I also added size attribute in the rquested_volume block, but could not able to fix this issue
Do you have any suggestions on how to resolve this? Thanks.

However, I’m now getting this error: Images with destination_type volume need to have a non-zero size specified.

This error is coming from Openstack, I wonder if you need to set the size in volume_attrs before the service.volumes.create(volume_attrs) call? Can you tell if the service.volumes.create() call is successful and it fails later on?

Hi @agrare,

This is the code now i have after adding debug statements:

This is the log generated for that:

The volume is created in opnstack, but not attached to instance:

So I definitely see a disk with :name=>"root" and :size=>0 in that "Checking volume with attributes" log line. Can you track down where that is coming from?

Yes @agrare that is coming from default_volume_attributes

Okay I thought if the flavor didn't have a root disk you were skipping the default_volume_attributes, can you tell how it is getting in there?

Hi @agrare,

We have fixed the issue and created a PR for it. Please take a look at it:

PR#894

Thank you for your valuable insights.

That's great @Dhamo1107 ! I do wonder how the default_volume_attributes values got in there if you skipped them via volumes_attrs_list = instance_type.root_disk_size > 0 ? [default_volume_attributes] : []. That's my only hesitation on merging what you have there as-is

Hi @agrare, the log indicates that the default_volume_attributes values showing name: root and size: 0 are associated with task ID 118, which I ran before changing the condition volumes_attrs_list = instance_type.root_disk_size > 0 ? [default_volume_attributes] : []. After modifying the condition, task ID 119 indicates skipping default volume attributes, which seems to be the misunderstanding. Task ID 119 correctly shows name: vol-test

Thank You

Fixed by #894