Uploaded image for project: 'Red Hat OpenStack Services on OpenShift'
  1. Red Hat OpenStack Services on OpenShift
  2. OSPRH-6215

unable to create an instance when hw_architecture=x86_64 is set in the image

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • rhos-18.0.4
    • rhos-18.0.0
    • openstack-nova
    • None
    • 2
    • False
    • Hide

      None

      Show
      None
    • False
    • Targeted
    • No Docs Impact
    • openstack-nova-27.5.2-18.0.20241112144714.15b1531.el9osttrunk
    • ?
    • ?
    • None
    • Hide
      .Setting `hw-architecture` or `architecture` on Image service (glance) image does not work as expected

      In RHOSO 18.0, the image metadata prefilter is enabled by default. RHOSO does not support emulation of non-native architectures. As part of the introduction of emulation support upstream, the image metadata prefilter was enhanced to support the scheduling of instances based on the declared VM architecture, for example, `hw_architecture=x86_64`.

      When nova was enhanced to support emulating non-native architecture by using image properties, a bug was introduced, because the native architecture was not reported as a trait by the virt driver.

      Therefore, by default, support for setting `hw_architecture` or `architecture` on an image was rendered inoperable.

      *Workaround:* To mitigate this bug, perform one of the following tasks:

      * Unset the `architecture`/`hw_architecture` image property. RHOSO supports only one architecture, x86_64. There is no valid use case that requires this to be set for an RHOSO cloud, so all hosts will be x86_64.
      * Disable the image metadata prefilter in the `CustomServiceConfig` section of the nova scheduler:
      +
      ----
      [scheduler]
      image_metadata_prefilter=false
      ----
      Show
      .Setting `hw-architecture` or `architecture` on Image service (glance) image does not work as expected In RHOSO 18.0, the image metadata prefilter is enabled by default. RHOSO does not support emulation of non-native architectures. As part of the introduction of emulation support upstream, the image metadata prefilter was enhanced to support the scheduling of instances based on the declared VM architecture, for example, `hw_architecture=x86_64`. When nova was enhanced to support emulating non-native architecture by using image properties, a bug was introduced, because the native architecture was not reported as a trait by the virt driver. Therefore, by default, support for setting `hw_architecture` or `architecture` on an image was rendered inoperable. *Workaround:* To mitigate this bug, perform one of the following tasks: * Unset the `architecture`/`hw_architecture` image property. RHOSO supports only one architecture, x86_64. There is no valid use case that requires this to be set for an RHOSO cloud, so all hosts will be x86_64. * Disable the image metadata prefilter in the `CustomServiceConfig` section of the nova scheduler: + ---- [scheduler] image_metadata_prefilter=false ----
    • Known Issue
    • Done
    • Moderate

      Octavia uploads a qcow2 image to glance with a property hw_architecture=x86_64 but in OSP18, placement denies the creation of a VM:

      We can reproduce this behavior in an install_yamls env + 1 edpm compute:

      $ openstack image set --property hw_architecture=x86_64 cirros

      $ openstack server create --flavor m1.small --image cirros --nic net-id=private test2 --security-group basic --wait
      Error creating server: test2

      In the placement logs:

      2024-04-08 13:47:46.492 14 DEBUG placement.requestlog [req-79d43bad-00ad-4faf-9eba-13076214c905 req-5170e778-675e-4919-a0f2-a7049b02c127 - - - - - -] Starting request: 10.217.1.47 "GET /allocation_candidates?limit=1000&resources=DISK_GB%3A2%2CMEMORY_MB%3A512%2CVCPU%3A1&root_required=COMPUTE_IMAGE_TYPE_QCOW2%2CHW_ARCH_X86_64%2C%21COMPUTE_STATUS_DISABLED" {}call{} /usr/lib/python3.9/site-packages/placement/requestlog.py:55
      2024-04-08 13:47:46.658 14 DEBUG placement.objects.research_context [req-79d43bad-00ad-4faf-9eba-13076214c905 req-5170e778-675e-4919-a0f2-a7049b02c127 175e41811c194d5c8fd21dce275ff937 068c352ea62c40b1b6f0782e9dcb6609 - - default default] found no providers satisfying required traits: {'COMPUTE_IMAGE_TYPE_QCOW2', 'HW_ARCH_X86_64'} and forbidden traits: {'COMPUTE_STATUS_DISABLED'} _process_anchor_traits /usr/lib/python3.9/site-packages/placement/objects/research_context.py:243
      2024-04-08 13:47:46.661 14 INFO placement.requestlog [req-79d43bad-00ad-4faf-9eba-13076214c905 req-5170e778-675e-4919-a0f2-a7049b02c127 175e41811c194d5c8fd21dce275ff937 068c352ea62c40b1b6f0782e9dcb6609 - - default default] 10.217.1.47 "GET /allocation_candidates?limit=1000&resources=DISK_GB%3A2%2CMEMORY_MB%3A512%2CVCPU%3A1&root_required=COMPUTE_IMAGE_TYPE_QCOW2%2CHW_ARCH_X86_64%2C%21COMPUTE_STATUS_DISABLED" status: 200 len: 53 microversion: 1.36

      It seems that it is a regression between OSP17.1 and OSP18

       

              rh-ee-auniyal Amit Uniyal
              rhn-support-gthiemon Gregory Thiemonge
              rhos-dfg-compute
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated: