When you’re trying to extend a disk on an Azure SQL VM that’s part of an Always On Availability Group—and the disk you want to expand is actually a Storage Spaces–based virtual disk—it’s not unusual to find that the “Extend Volume” option is grayed out in Disk Management. Although the individual physical disks in Server Manager report their full capacity (about 511 GB in your case), the free space shown in Computer Management (256 GB per disk) doesn’t always translate into immediately extendable space for the virtual disk. This discrepancy is typically due to how Storage Spaces allocates and tracks space within its storage pool.
Users have noticed similar quirks in other scenarios where, despite having apparent free space on the physical disks, the “Extend Volume” option remains unavailable. This is because the extension isn’t as straightforward as on a traditional partition where contiguous unallocated space sits right next to the partition that needs to be extended.
• Check the storage pool’s status and capacity using PowerShell. Commands such as
Get-StoragePool
Get-VirtualDisk
can show you the total capacity, allocated size, and whether your virtual disk is thin provisioned or created with a fixed size. This can help determine if the disk is “locked in” to a maximum size despite available physical space.
• Verify that the free space shown on each physical disk isn’t simply a quirk of how Windows reports available capacity when using Storage Spaces. Sometimes the space isn’t contiguous in the way that Disk Management expects.
• If your disk is a Managed Disk from Azure that was later configured into a Storage Spaces pool, remember that—even if you can normally extend Managed Disks from the Azure portal—the Storage Spaces layer can add an extra level of complexity.
1. Use PowerShell to Extend the Virtual Disk
If your virtual disk was created with thin provisioning or if there’s extra capacity available in the storage pool, you might be able to extend it using a PowerShell command. For example, once you’ve verified available capacity, you can try:
Set-VirtualDisk –FriendlyName "MyLogDisk" –Size <new size>
This command forces the virtual disk to grow to the specified size, after which you would use Disk Management or DiskPart to extend the partition within the OS.
2. Add an Additional Physical Disk to the Storage Pool
If the Storage Spaces virtual disk was configured with fixed provisioning and cannot use the unallocated capacity on existing drives, the simplest option might be to add another disk to the storage pool. This extra disk will introduce additional free capacity into the pool that can then be assigned to your virtual disk.
3. Check Azure Portal for Managed Disk Resizing
If your disk is a Managed Disk that was later included in a Storage Spaces configuration, you may need to first extend the disk from the Azure portal. After resizing the Managed Disk, boot into the VM and extend the partition. Keep in mind that the Storage Spaces layer might require additional manual steps to recognize and use that new capacity.
4. Consider Third-Party Tools with Extreme Caution
In some cases, users have resorted to utilities like GParted when built-in tools are too limited. However, these tools are best left for scenarios where you can schedule downtime and take full backups—especially in a production Always On scenario.
• Double-check that your Storage Spaces pool displays actual free capacity before attempting any modification.
• If your VM is part of an Always On Availability Group, consider performing these changes on the secondary server first. This minimizes the risk of interrupting synchronization and can help you validate your approach before a failover.
• Review Microsoft’s documentation on extending Storage Spaces volumes and Managed Disks in Azure, since the interplay between Azure platform-level configurations and Windows’ Storage Spaces can introduce unexpected behavior.
This type of challenge isn’t unique—several community threads have discussed similar behaviors when dealing with Storage Spaces and non-contiguous free space. With careful diagnostics and a measured deployment plan, you should be able to reclaim the needed capacity for your SQL log drive and restore synchronization in your Always On Availability Group.
By following these steps and executing any storage changes cautiously, you’ll improve your server’s resilience—and maybe even save yourself a few headaches down the line.
Source: Spiceworks I am unable to extend drive on Azure SQL VM server
Understanding Storage Spaces and Virtual Disks
Storage Spaces allows you to combine multiple physical disks into one storage pool and then carve out a “virtual disk” (or storage space) that your OS sees as a single volume. When you set up a Storage Spaces–based volume with a “Simple” layout (essentially striping the data across the disks for performance but without resiliency), you often decide on a maximum size when the virtual disk is created. Even if the underlying physical disks have free capacity, if the virtual disk was configured with a fixed size or created as a non–thin-provisioned volume, the built-in Disk Management tools may not recognize additional free space automatically.Users have noticed similar quirks in other scenarios where, despite having apparent free space on the physical disks, the “Extend Volume” option remains unavailable. This is because the extension isn’t as straightforward as on a traditional partition where contiguous unallocated space sits right next to the partition that needs to be extended.
Diagnosing Why the Extend Option Is Disabled
Before taking further action, it’s important to verify a couple of key points with your current Storage Spaces setup:• Check the storage pool’s status and capacity using PowerShell. Commands such as
Get-StoragePool
Get-VirtualDisk
can show you the total capacity, allocated size, and whether your virtual disk is thin provisioned or created with a fixed size. This can help determine if the disk is “locked in” to a maximum size despite available physical space.
• Verify that the free space shown on each physical disk isn’t simply a quirk of how Windows reports available capacity when using Storage Spaces. Sometimes the space isn’t contiguous in the way that Disk Management expects.
• If your disk is a Managed Disk from Azure that was later configured into a Storage Spaces pool, remember that—even if you can normally extend Managed Disks from the Azure portal—the Storage Spaces layer can add an extra level of complexity.
Potential Solutions to Extend Your Disk
Here are several approaches you might consider to reclaim or use that extra capacity:1. Use PowerShell to Extend the Virtual Disk
If your virtual disk was created with thin provisioning or if there’s extra capacity available in the storage pool, you might be able to extend it using a PowerShell command. For example, once you’ve verified available capacity, you can try:
Set-VirtualDisk –FriendlyName "MyLogDisk" –Size <new size>
This command forces the virtual disk to grow to the specified size, after which you would use Disk Management or DiskPart to extend the partition within the OS.
2. Add an Additional Physical Disk to the Storage Pool
If the Storage Spaces virtual disk was configured with fixed provisioning and cannot use the unallocated capacity on existing drives, the simplest option might be to add another disk to the storage pool. This extra disk will introduce additional free capacity into the pool that can then be assigned to your virtual disk.
3. Check Azure Portal for Managed Disk Resizing
If your disk is a Managed Disk that was later included in a Storage Spaces configuration, you may need to first extend the disk from the Azure portal. After resizing the Managed Disk, boot into the VM and extend the partition. Keep in mind that the Storage Spaces layer might require additional manual steps to recognize and use that new capacity.
4. Consider Third-Party Tools with Extreme Caution
In some cases, users have resorted to utilities like GParted when built-in tools are too limited. However, these tools are best left for scenarios where you can schedule downtime and take full backups—especially in a production Always On scenario.
Best Practices and Cautions
• Always back up your critical data and log files before modifying disk configurations or extending volumes.• Double-check that your Storage Spaces pool displays actual free capacity before attempting any modification.
• If your VM is part of an Always On Availability Group, consider performing these changes on the secondary server first. This minimizes the risk of interrupting synchronization and can help you validate your approach before a failover.
• Review Microsoft’s documentation on extending Storage Spaces volumes and Managed Disks in Azure, since the interplay between Azure platform-level configurations and Windows’ Storage Spaces can introduce unexpected behavior.
Conclusion
The root of your issue appears to be that while the physical disks show additional free space, the virtual disk created under Storage Spaces is constrained by either its fixed provisioning or a configuration limit set at creation. By inspecting the storage pool with PowerShell, verifying the provisioning type, and considering options like extending via PowerShell commands or adding new physical disks to the pool, you can overcome the limitations in Windows Disk Management that leave the “Extend Volume” option grayed out.This type of challenge isn’t unique—several community threads have discussed similar behaviors when dealing with Storage Spaces and non-contiguous free space. With careful diagnostics and a measured deployment plan, you should be able to reclaim the needed capacity for your SQL log drive and restore synchronization in your Always On Availability Group.
By following these steps and executing any storage changes cautiously, you’ll improve your server’s resilience—and maybe even save yourself a few headaches down the line.
Source: Spiceworks I am unable to extend drive on Azure SQL VM server
