Hi all, Thank you for the clarifications and feedback.
Based on your replies, I understand that Ceph to local (NVMe) volume migration is not clearly documented or guaranteed to be supported, and that the behavior I observed via Scale Instance may be more of a side effect than an intended or supported workflow. I will therefore treat this as unsupported behavior, make sure to thoroughly check volume and filesystem integrity after such operations, and avoid relying on this approach in production. If anyone has additional insights, recommendations, or alternative supported approaches for this use case, I would be happy to hear them. Thanks again for sharing your experience. Best regards, Nicolas De : Wei ZHOU <[email protected]> Date : lundi, 22 décembre 2025 à 14:30 À : [email protected] <[email protected]> Objet : Re: Shared to Local (NVMe) volume migration via Scale Instance – expected behavior? (CloudStack 4.19.1.0) Hi Nicolas, I have not tested the volume migration from ceph to local. But NFS to local migration worked in my testing. Just bear in mind that when you migrate the volume, you need to create a Local disk offering and replace the disk offering of volume with it. -Wei 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 > > >
