| Summary: | Boot OpenStack instance from a Volume | ||
|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Shane Boulden <sboulden> |
| Component: | Documentation | Assignee: | Red Hat CloudForms Documentation <cloudforms-docs> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat CloudForms Documentation <cloudforms-docs> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.5.0 | CC: | cpatters, jhardy, jocarter, mfeifer, niroy, obarenbo |
| Target Milestone: | GA | ||
| Target Release: | cfme-future | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | doc | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-08-06 19:21:46 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
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.
|
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.