Feature Overview (mandatory - Complete while in New status)
As RHOSO 18 shifts the default machine type from the legacy i440fx to the modern q35 architecture, customers migrating existing workloads from older RHOSP versions face potential boot failures or driver instabilities if the machine type is changed abruptly during migration. This feature enables os-migrate to preserve or explicitly set the hw_machine_type in the volume_image_metadata during the migration workload phase. This ensures "pixel-perfect" hardware emulation parity between the source and destination clouds, reducing post-migration manual intervention and minimizing downtime.

Goals (mandatory - Complete while in New status)

• Goal: Provide an automated mechanism to carry over or override the machine type metadata during the volume-to-volume migration process.

• Who benefits: Cloud Operators and Infrastructure Architects performing Parallel Cloud Migrations (PCM) who need to move legacy Windows or Linux workloads that are sensitive to chipset changes.

• Current State: Today, migrated volumes may default to the destination's q35 default, potentially breaking instances that expect i440fx hardware paths.

• Future State: Operators can define the required machine type in their migration manifests, ensuring the instance remains bootable and stable immediately after the migration completes.

Requirements (mandatory -_ Complete while in Refinement status):

Done - Acceptance Criteria (mandatory - Complete while in Refinement status):

• The os-migrate data structures are updated to include hw_machine_type.

• During the export phase, the tool successfully captures existing machine types from the source.

• During the import phase, the tool correctly sets the volume_image_metadata on the Cinder volume in the RHOSO cloud.

• Successful boot-up of a migrated instance on RHOSO 18 using the legacy pc (i440fx) machine type.

• Functional tests verify that if no metadata is present, the system behaves according to destination defaults without erroring out.

Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement 

Main Success Scenario: Automated Preservation

1. Export: Operator runs os-migrate export. The tool detects hw_machine_type: pc-i440fx-rhel7.6.0 on the source volume.

1. Manifest: The exported YAML file includes the hw_machine_type attribute.

1. Import: Operator runs os-migrate import. The tool creates the volume in RHOSO and applies the metadata.

1. Launch: The instance is launched on RHOSO 18; Nova recognizes the metadata and emulates the legacy chipset.

Alternative Scenario: Manual Upgrade

1. Operator decides to upgrade the machine type during migration.

1. Operator manually edits the migration YAML to change i440fx to q35.

1. os-migrate applies the new metadata, and the instance boots with the modern architecture.

Out of Scope __(Initial completion while in Refinement status):
N/A

Documentation Considerations __(Initial completion while in Refinement status):

Changes in the upstream documentation

Questions to Answer __(Initial completion while in Refinement status):
Include a list of refinement / architectural questions that may need to be answered before coding can begin.
<your text here>

Background and Strategic Fit (Initial completion while in Refinement status):

This feature is critical for enterprise readiness. Many customers are migrating from RHOSP 13/16.x where i440fx was the standard. Without this, migrations of sensitive workloads (like legacy Windows or specialized appliances) would require high-touch manual CLI work to fix metadata after the transfer, negating the value of os-migrate automation.

Customer Considerations __(Initial completion while in Refinement status):
Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.
<your text here>

Team Sign Off (Completion while in Planning status)

• All required Epics (known at the time) are linked to the this Feature
• All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
• Add - Reviewers name, Team Name
• Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
• Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone

• …