Feature Request Overview

The user goal is to control the placement of migrated VMware virtual machines (VMs) onto specific OpenStack compute nodes using the Red Hat OpenStack VMware Migration Toolkit.

Currently, after flavor selection/creation, the VM could be scheduled onto any eligible compute host. This feature is needed to ensure that workloads requiring specific attributes—such as dedicated hardware, specific VLANs, or licensing restrictions—are reliably placed on compute nodes that possess those attributes, which are managed within OpenStack using Host Aggregates.

Business justification

This feature provides significant benefits by allowing customers to:

Enforce Compliance and Resource Separation: Customers can ensure that workloads with strict requirements (e.g., regulatory compliance, specific networking needs like certain VLANs, or specialized hardware like GPUs or SSD-only storage) are placed only on the compute hosts configured to meet those needs.

Optimize Resource Utilization: By isolating specialized or licensed hardware/resources into specific host aggregates, customers can prevent those resources from being consumed by general-purpose workloads, ensuring the resources are available for the critical workloads that require them.

Improve Performance Predictability: Workloads requiring dedicated, high-performance, or specialized hardware (e.g., a specific CPU architecture or high-end NICs) can be reliably placed in aggregates containing only that hardware, leading to more predictable performance.

Leverage Existing OpenStack Functionality: It allows customers to fully leverage the established Host Aggregates and associated Availability Zone functionality within OpenStack to manage and segment their compute resources effectively during the migration process.

Functional requirements

Host Aggregate Selection Input: The Red Hat OpenStack VMware Migration Toolkit must provide an option (e.g., a field, a dropdown list, or a configuration parameter) for the user to specify the target Host Aggregate or Availability Zone during the migration setup process.

Flavor Integration with Host Aggregates:

Existing Flavor Match: If use_existing_flavor is true, the best match algorithm must not only find the closest existing flavor but also check if that flavor is associated with the selected target Host Aggregate (via its metadata/properties). If the flavor is not compatible or associated, the user must be informed, and the process should offer to create a new, compatible flavor (Requirement 3).

New Flavor Creation: If a new flavor is being created (either because use_existing_flavor is false or no suitable existing flavor was found), the new flavor must be automatically created with the appropriate flavor extra-specs that enforce scheduling onto the specified target Host Aggregate.

Validation and Error Handling: The tool must validate that the specified target Host Aggregate exists and is available. If an invalid or unavailable aggregate is selected, the migration process must be blocked, and a clear error message must be presented to the user.

Placement During Migration: Upon final execution, the migrated OpenStack VM instance must be scheduled and booted only on a compute host that belongs to the specified target Host Aggregate.

Describe the customer impact

This feature has a high positive impact on customers who require fine-grained control over VM placement. It directly addresses the need to guarantee that migrated workloads land on compute nodes with specific, requisite hardware (e.g., dedicated GPUs, high-speed storage, or specific CPU features) or network configurations (e.g., specific VLAN connectivity). This control is critical for maintaining licensing compliance and performance Service Level Agreements (SLAs) for specialized workloads post-migration.

(Optional) Point of contact

• Carlos Franciosi 
•  

(Optional) Additional links

Click More > Link to add any links to issues, such as an outcome, that are related to this feature request.

Feature Overview (mandatory - Complete while in New status)
An elevator pitch (value statement) that describes the Feature in a clear, concise way. ie: Executive Summary of the user goal or problem that is being solved, why does this matter to the user? The “What & Why”... 
<your text here>

Goals (mandatory - Complete while in New status)
Provide high-level goal statement, providing user context and expected user outcome(s) for this Feature

• Who benefits from this Feature, and how? 
• What is the difference between today’s current state and a world with this Feature?
  <your text here>

Requirements (mandatory -_ Complete while in Refinement status):
A list of specific needs, capabilities, or objectives that a Feature must deliver to satisfy the Feature. Some requirements will be flagged as MVP. If an MVP gets shifted, the Feature shifts. If a non MVP requirement slips, it does not shift the feature.

 
Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Feature. The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view
…
<your text here>
Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement status):
Include use case diagrams, main success scenarios, alternative flow scenarios.
<your text here>
Out of Scope _ _(Initial completion while in Refinement status):
High-level list of items or persona’s that are out of scope.
<your text here>
Documentation Considerations _ _(Initial completion while in Refinement status):
Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation..
<your text here>
 
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):
Provide any additional context is needed to frame the feature.
<your text here>
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

  Reviewed By	Team Name	Accepted	Notes