kvm: fix direct-download live storage migration

[Kunalbehbud]

Reopened as a fresh PR after #13084 was auto-closed by GitHub following a history correction on the branch (author identity fix, no code/content change — verified via unchanged tree hashes). Carrying over the original description below; #13084 has the prior review history from @nvazquez and the successful packaging run.

Description

This PR fixes live storage migration for KVM instances whose migrated volumes are backed by direct-download templates.

The problematic path is linked-clone live storage migration. For that mode, libvirt expects the rest of the backing chain to already exist on the destination and to match the source. That assumption is not safe for direct-download backed volumes, where the template may have been bypassed or staged directly on primary storage. When such a volume is part of the actual migration set, this PR forces the KVM migration request to use full-clone storage migration instead.

A few related edge cases are handled in the same path:

• the full-clone decision ignores volumes that are skipped from the migration request, such as same-pool PowerFlex volumes or volumes rejected by shouldMigrateVolume
• VolumeDataFactoryImpl now carries the template directDownload flag consistently across its getVolume(...) variants, including volumes whose template was removed later
• copied template references are updated instead of blindly persisted, and missing source references now fail with a useful error instead of a later NPE
• ModifyTargetsCommand failures preserve the agent error details and empty connected-path answers fail with a clearer exception

This keeps the change scoped to the KVM storage migration bug. It does not try to mix linked-clone and full-clone per disk, since the current KVM/libvirt migration command chooses the storage migration mode for the VM migration request as a whole.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

N/A. This is a backend KVM storage migration fix.

How Has This Been Tested?

Targeted unit tests:

mvn -pl engine/storage/datamotion,engine/storage/volume -am \
  -Dtest=AncientDataMotionStrategyTest,KvmNonManagedStorageSystemDataMotionTest,StorageSystemDataMotionStrategyTest,VolumeDataFactoryImplTest \
  -DfailIfNoTests=false -Dsurefire.failIfNoSpecifiedTests=false test

Result: 74 tests run, 0 failures, build success.

Manual verification was also done in a two-host KVM 4.22 test environment:

• registered a direct-download Rocky Linux template
• deployed an instance from that template
• live migrated the instance with storage from host A to host B
• live migrated it back from host B to host A
• confirmed the VM stayed running after each migration
• confirmed management logs showed the expected full-clone fallback for the direct-download backed volume

How did you try to break this feature and the system with this change?

Covered the boundary cases that are most likely to regress this path:

• mixed migration requests with a direct-download volume and a normal volume
• direct-download volumes that are skipped and should not force the rest of the request to full clone
• existing and missing copied template references
• destination template references whose backing path differs from the source backing path
• ModifyTargetsCommand returning a generic failed Answer
• ModifyTargetsAnswer returning no connected paths
• volumes with no template ID, to avoid unnecessary template lookups

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache CloudStack community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md)
Here are some useful points:

• In case of a new feature add useful documentation (raise doc PR at https://github.com/apache/cloudstack-documentation)
• Be patient and persistent. It might take some time to get a review or get the final approval from the committers.
• Pay attention to the quality of your code, ensure tests are passing and your PR doesn't have conflicts.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Issues, Mailing list and Slack.
• Be sure to read the CloudStack Coding Conventions.
  Apache CloudStack is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@cloudstack.apache.org (https://cloudstack.apache.org/mailing-lists.html)
  Slack: https://apachecloudstack.slack.com/

[github-actions]

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.