-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
False
-
-
False
-
?
-
rhos-ops-day1day2-migrations
-
None
-
-
-
-
-
Critical
To Reproduce Steps to reproduce the behavior:
- Deploy RHOSP16.2 and RHOSO18
- Create a bootable volume with volume_image_metadata, i.e. hw_machine_type
- Run os-migrate for migration from OSP16.2 to RHOSO18
Expected behavior
- volume_image_metadata property is preserved.
Bug impact
- By the lack of implementation, the user cannot preserve the critical metadata for new deployment, i.e. hw_machine_type.
In RHOSO18, hw_machine_type is one of key metadata because the instances running on old deployment run with i440fx architecture though RHOSO18 default is q35.
To preserve the old machine type, the user needs to add hw_machine_type to volumes.
However, without the implementation, volume_image_metadata isn't copied to new deployment and instances which assumes i440fx booted up with q35 architecture. That causes unintended network device assignment or lost the network configuration because the OS in migrated instances distinguish the hardware is changed.
Known workaround
- N/A
Additional context
- Lack off this implementation affect to user's migration testing
- is duplicated by
-
OSPRH-21956 Missing property volume_image_metadata in OSP migrations
-
- Closed
-