compute: RequestSpec sanitization for cross-HV resize

[anokfireball]

Sanitize VMware-specific image properties directly on the canonical RequestSpec before scheduling, matching how request_spec.flavor is already handled in the cold migrate flow.

The sanitizer mutates request_spec.image.properties in place and returns a dict of original values. After task.execute() succeeds, the conductor persists this into
MigrationContext.old_image_properties (via instance.save()) before calling request_spec.save(). This ordering ensures the rollback copy is always available if request_spec has been rewritten.

Changes:

• nova/compute/utils.py: add sanitize_image_props_for_kvm()
• nova/conductor/tasks/migrate.py: call sanitizer in _execute()
• nova/conductor/manager.py: persist old_image_properties to MigrationContext before request_spec.save()

Change-Id: I4f7035358a9a7f46d942bfad07d748d1d333f8c5

[joker-at-work]

Do we need to save the request spec info somewhere? Are these same values not replicated to instance.image_meta or are these just a subset?

[anokfireball]

From my current understanding, we do need to persist them in request_spec. These properties do overlap with what ends up in instance.image_meta via system_metadata, but (AFAICT) Nova treats those as separate things. Later resize/cold-migrate scheduling reloads RequestSpec from request_specs and uses request_spec.image; it does not rebuild that from instance.image_meta. You can see the same pattern in rebuild, where Nova explicitly updates and saves request_spec.image when the scheduler needs to see the new image.

Relevant comment from upstream:

NOTE(mriedem): Using request_spec.image here is potentially
dangerous if it is not kept up to date (i.e. rebuild/unshelve);
seems like the sane thing to do would be to pass the current
instance.image_meta since that is what MoveClaim will use for
any NUMA topology claims on the destination host...

[joker-at-work]

Oh, yes, I was just wondering if they'd contain the same, if we really need to extend the migration object or could just use them from there.

What happens if the migration succeed and is not rolled back? Then instance.image_meta and request_spec.image are out of sync. Would this be updated in a follow-up?

[anokfireball]

This PR is primarily about the scheduling side: It ensures the request_spec.image is sanitized and persisted so later scheduling decisions are based on KVM-compatible image metadata. Updating instance.image_meta / system_metadata is still required as part of the runtime resize flow, but is handled separately (partially on the WIP branch). For resize revert, this PR already stores the original image properties in MigrationContext.old_image_properties; the actual restoration logic is part of the follow-up revert work/ticket.

Sidenote: There is this previously attempted approach with a flow closer to what you might have in mind. It does not persist the data changes until much later (around resize confirmation) and only overrides the scheduling request temporarily.

[joker-at-work]

I have nothing in mind, just given the limited implementation in this PR am missing the rest of the picture. Hence asking questions for my understanding.