An Azure service that provides enterprise-grade file shares powered by NetApp.
Hi Ming Yan,
Thanks for posting question in Microsoft Q&A forum,
I have a volume in a Premium Qos capacity pool. I just create a new capacity pool with Flexible Qos. I went to the Volume, right click -> Change Pool, the little "Change Pool" panel comes up on the right with a drop down selection for "Pools", however the selection is empty with a message "No Available Items", so I cannot proceed.
According to this MS-Document [Dynamically change the service level of an Azure NetApp Files volume | Microsoft Learn],
Volumes cannot be directly moved from Premium QoS to Flexible QoS capacity pools in Azure NetApp Files.
- Flexible service level pools require manual QoS and cannot accept volumes from Standard, Premium, or Ultra pools, which use auto QoS by default. Documentation explicitly states that Premium (auto QoS) volumes cannot move to Flexible (manual QoS only).
According to this MS-Document [Create a capacity pool for Azure NetApp Files | Microsoft Learn]
The Azure capacity pool creation doc explicitly states that volumes in Flexible service-level capacity pools can’t be moved to another pool, nor can volumes be moved into a Flexible pool:
“Volumes in Flexible service level capacity pools can't be moved to another capacity pool. You also can't move volumes into a Flexible service level capacity pool.”
This is the key block that confirms the behavior you are seeing in the portal, the portal hides pool you cannot move to.
- You can move volumes between pools of the same QoS type (e.g., Premium → Standard) using Change Pool.
- You cannot move volumes into or out of Flexible service level pools.
- Flexible is currently only supported on new manual QoS pools and is a distinct category that doesn’t participate in the normal move workflow
Reference:
Service levels for Azure NetApp Files | Microsoft Learn
Update:
Volumes from Premium QoS pools can't be moved to Flexible ones (portal, CLI like az netappfiles volume pool-change, or API) due to service level mismatch. Snapshot replication to a new volume is the go-to workaround for low downtime.
We'll work on improving the docs and AI troubleshooter to highlight this clearly—your feedback helps a ton. In the meantime, drop suggestions via the Azure Feedback Portal
Kindly let us know if the above helps or you need further assistance on this issue.
Please do not forget to
and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.