Hide Forgot
Description of problem: The RedHat Cloudforms 4.0 documentation notes that an Openstack instance can be booted from an existing, bootable volume using the following code: prov.set_option( :clone_options, { :image_ref => nil, :block_device_mapping_v2 => [{ :boot_index => 0, :uuid => "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx", :device_name => "vda", :source_type => "volume", :destination_type => "volume", :delete_on_termination => false }] } ) The following bootable OpenStack volume was used to test this code, setting the "uuid" above to the object's ems_ref: <MiqAeServiceCloudVolume:0xe233bc @object=#<CloudVolume id: 1000000000026, type: nil, ems_ref: "06bb82b3-2087-4f38-be8a-124d0dfa446d", size: 1073741824, ems_id: 1000000000003, availability_zone_id: 1000000000007, cloud_volume_snapshot_id: nil, name: "cirros image", status: "available", description: "Volume test", volume_type: "iscsi", bootable: true, creation_time: "2016-04-28 03:05:09", cloud_tenant_id: nil>, @virtual_columns=["region_description", "region_number"], @associations=["attachments", "availability_zone", "base_snapshot", "cloud_tenant", "cloud_volume_snapshots", "ext_management_system"]> Version-Release number of selected component (if applicable): 5.5.2.4.20160127105142_395c086 How reproducible: - Override the openstack_PreProvision method (in the ManageIQ/Cloud/VM/Provisioning/StateMachines/Methods class) with the above code, and setting the uuid to the ems_ref of a bootable volume known to exist in the OpenStack tenant. Actual results: The call to the OpenStack API produces the following error: [Excon::Errors::BadRequest]: Expected([200, 202]) <=> Actual(400 Bad Request) excon.error.response :body => "{\"badRequest\": {\"message\": \"Invalid input for field/attribute imageRef. Value: None. None is not of type 'string'\", \"code\": 400')] Expected results: The OpenStack API accepts the block_device_mapping without an image_ref specified, and the provisioned VM is able to boot from the specified volume. Additional info: Provisioning was initiated from a service catalogue item using the $evm.execute('create_provision_request') method, and appropriate arguments. Document URL: https://access.redhat.com/documentation/en/red-hat-cloudforms/version-4.0/methods-available-for-automation/#sect_vm_provision_task_miq_provision Section Number and Name: 1.25.3.2. Booting OpenStack Instances from Volume Describe the issue: The code provided in this example does not produce expected results. Suggestions for improvement: Provide example code that results in an OpenStack VM able to boot from a bootable volume.
A workaround for OpenStack RDO Liberty is to pass an empty string to the :image_ref value, and any integer as the volume_size. ie; prov.set_option( :clone_options, { :image_ref => "", :block_device_mapping_v2 => [{ :boot_index => 0, :uuid => "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx", :device_name => "vda", :source_type => "volume", :destination_type => "volume", :volume_size => 0, :delete_on_termination => false }] } ) The image_ref and volume_size are ignored by Nova, and the bootable volume is attached as /dev/vda. The instance successfully boots from the volume. This workaround also supports creating a bootable volume from an image, where the uuid in this case is the image template on the OpenStack provider. ie; prov.set_option( :clone_options, { :image_ref => "", :block_device_mapping_v2 => [{ :boot_index => 0, :uuid => "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx", :device_name => "vda", :source_type => "image", :destination_type => "volume", :volume_size => 1, :delete_on_termination => false }] } ) This creates a 1GB bootable volume, and attaches it to the instance as /dev/vda.