The storage type and offering for the volume(s) remain the same, after migrating VM with volumes (in VMware) and doesn't match with the underlying storage pool.

[sureshanaparti]

[VMware] The storage type and offering for the volume(s) remain the same, after migrating VM with volumes (from Local to Shared storage or vice versa, in VMware) and doesn't match with the underlying storage pool.

ISSUE TYPE

• Bug Report
• Improvement Request

COMPONENT NAME

Volume

CLOUDSTACK VERSION

main

CONFIGURATION

Tested with CS + VMware 6.7 + Local Storage + Shared Storage, with Advanced networking

OS / ENVIRONMENT

SUMMARY

The VM migration with volumes, is supported across different storage types (Local and Shared) for VMware. Once the migration is performed, the storage type / offering still points to the old storage type / offering, doesn't match with the underlying storage pool.

ROOT Disk migrated to Shared Pool from Local storage =>

DATA Disk migrated to Local Pool from Shared storage =>

STEPS TO REPRODUCE

• Create a VM with ROOT disk in Local storage, and DATA disk in Shared storage.
• Perform VM migration with volumes, with ROOT disk maps to Shared storage and DATA disk maps to Local storage.

EXPECTED RESULTS

Storage Type should indicate the correct type (Local / Shared) for the volume after migration.

ACTUAL RESULTS

Storage Type points to incorrect type for the volume after migration.

[harikrishna-patnala]

This needs change in volume response preparation. CloudStack prepares volume response and fills the data based on the disk offering. Here in this case storage pool type can be used instead of offering.

[sureshanaparti]

This needs change in volume response preparation. CloudStack prepares volume response and fills the data based on the disk offering. Here in this case storage pool type can be used instead of offering.

@harikrishna-patnala what about the disk offering, can that be updated with relevant offering after migration?

[harikrishna-patnala]

I don't see the option to specify disk offering for each volume during migrateVirtualMachineWithVolume API. So either that has to be added to the API as an improvement or admin needs to change the disk offering manually after migration operation to reflect the appropriate offering.