Nicolas, there are all kinds of supported Type1->Type2 migrations for storage type. Ceph to NVMe I am not aware of and also not of which versions support what. Best to check your volume for integrity after scaling/migrating. Scale should not be able to behave differently than vanilla migrate, but live migrate and/or VM-migrate, might.
Others might know more?? On Mon, Dec 22, 2025 at 10:00 AM Nicolas LEPRON <[email protected]> wrote: > Hello, > > I’m currently running Apache CloudStack 4.19.1.0 and testing volume > migrations, and I’d like to clarify whether what I’m seeing is expected > behavior. > > When I try to migrate a volume directly from shared storage (Ceph) to > local NVMe storage, CloudStack refuses the operation with the following > error: > > Migrate volume > You cannot move the volume to a shared storage and assign a disk offering > for local storage and vice versa. > > From my understanding, this is expected and consistent with CloudStack’s > design: a volume should not be able to change its storage type (shared ↔ > local) through a direct migration. > > However, I recently noticed something unexpected: > > If I first perform a Scale Instance operation and change the compute > offering, and then retry the volume migration, the migration succeeds. > In this case, I am effectively able to migrate a volume from shared > storage to local NVMe storage. > > So I’m wondering: > > * Is this behavior expected and supported? > > * Does the scale instance operation change internal constraints that > allow this migration? > > * Or could this be an unintended side effect or bug? > > I’d like to make sure I’m not missing something obvious or relying on > behavior that might not be safe or supported. > > Thanks in advance for your feedback. > > Best regards, > Nicolas > > > -- Daan
