Hi Amaan,
By Officially, decreasing the size of an existing OS disk on a VM is not supported (however you can decrease the size of a data disk):
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/expand-os-disk
Shrinking an existing disk isn’t supported and may result in data loss.
The steps to accomplish this are:
Choose the best disk size
Shrink the partition size in the VM
Export the managed disk to a VHD
Shrink the exported VHD
Create a new managed disk from the VHD
Create a new VM from the new managed disk
Optionally cleanup the old resources
Let’s now go into the steps in details:
- Choose the best disk size
Since disk sizes are charged to the rounded up nearest size, you should pick the best size accordingly. For example, if you choose 35GB, you’ll be charged for 64GB. Refer to this table for more details.
- Shrink the partition size in the VM
One simple PowerShell to run inside the VM while it’s running (adjust the size accordingly):
- Export the managed disk to a VHD
Make sure the VM is deallocated, and then run the following commands (adjust variables accordingly):
- Shrink the exported VHD
This is a tough one, it’s basically not supported to shrink a VHD on Azure. I always thrive to do things in the most efficient way possible. Knowing that Azure uses fixed size VHDs and that resizing them is basically moving around a 512-bytes footer, it does not make sense to me to move around several GBs of data. When looking around, I found WindowsAzureDiskResizer, a tool built in 2013 by Maarten Balliauw that does just this. The tool is efficient since it just rewrites the footer at the end of blob. Although it worked fine for me, I must point out Maarten’s disclaimer:
Big disclaimer: use the provided code on your own risk! I’m not responsible if something breaks! The provided code is as-is without warranty! I have tested this on a couple of data disks without any problems. I’ve tested this on OS disks and this sometimes works, sometimes fails. Be warned.
Though it might seem frightening, keep in mind the whole process described here is non-destructive since we haven’t touched the original VM other than shrinking the partition size, which can easily be undone. We are building a new VM with a new managed disk, so you can always go back to the original one.
That being said, the first version of the tool posted above did not support shrinking, so I forked the repo, updated the dependencies to the latest versions and created a new release for convenience. Again, Maarten’s disclaimer still applies here.
Before using the tool, run the following commands in the same context as the previous step to get the full blob URI including a shared access
If you’re still not comfortable using the tool, you can always go the long way and download the whole virtual disk to a machine with Hyper-V client tools installed, use the edit disk feature or the Resize-VHD cmdlet to shrink the virtual disk and reupload it to Azure. Note that you might have to convert back and forth from the VHD and VHDX formats (Azure only supports VHD at this time).
- Create a new managed disk from the VHD
No matter the technique used, your smaller VHD should now be uploaded to Azure. To create a new managed disk, run the following commands in the same context as previous steps (adjust variables accordingly):
- Create a new VM from the new managed disk
There’s several ways to accomplish this one, you could use PowerShell or an ARM template for example. Whatever option you choose, you need to use “Attach” option for the OS Disk rather than the “FromImage” option. This will create a specialized VM, in other words, the VM is not expected to be generalized (or sysprep’d). Note there’s a little caveat: the computer name will remain empty in the Azure portal, since it’s currently only appears for generalized VMs. Here’s a PowerShell sample you could use, it must be run in the same context as previous steps (adjust variables accordingly):
- Optionally cleanup the old resources
You should now have a fully functional VM with a shrunken managed disk. If not, remember you can always go back to the original VM. Once you are satisfied with your new VM, you could choose to cleanup the old resources like the VM, it’s managed disk, network interface, etc. Obviously, once you’ve deleted the original resources, there’s no going back. You can also delete the temporary VHD used to create the new managed disk. Note that if you do, you won’t be able to reattach the same managed disk to another VM since the source VHD is required when the VM is created.
So those are the steps to shrink a managed disk. Most of these scripts are based on this repo, so check it out for more samples. When creating brand new VMs, we are now seeing images offering smaller sizes by default like the one labelled “[smalldisk] Windows Server 2016 Datacenter”. If such an image does not exist currently, you could build one yourself. Since the VM would be generalized, you would not run into the computer name caveat discussed at step #6.
Hope it helps!