IaaS Management Studio allows you to resize any VHD, how does it works under the hood ?
To understand that, we need to take a look at the VHD format. Azure supports only fixed size VHD, which means that a VHD is as big as the maximum of data you need to save in it. In summary, if you want a 30GB VHD, then, the logical size of your VHD will be 30GB, even if you actually use only 10GB.
This is not a problem in Azure since you are only billed for 512 bytes ranges that you really use. A new empty new 100 GB VHD (logical size) page blob will cost you in reality 512 Bytes (physical size) of storage.
Why 512 Bytes ? Because a fixed VHD only have a footer of 512 bytes at the end of the VHD file. The rest is raw data as you would find in any non virtual drive with MBR, partition and everything you are used to. Here is the format, Diagram generated from classes taken from the excellent DiscUtils library.
So how do we resize the VHD ?
Step 1 : retrieve the current footer and build the new footer
We open the blob, go to the end, read the bytes and parse it.
Then we modify the footer data structure in memory. We update the CurrentSize and OriginalSize of the VHD, make sure it rounds to the nearest whole MB.
We then update the geometry of the VHD disk. Some old system use CHS addressing to write data on a disk instead of a linear system (LBA addressing). This is just a way to reference a byte address with a Cylinder/Head/Sector tuple instead of a simple offset. Such addressing depends on the size of the disk (large disks have more head and cylinder).
However, modern OS do not use such addressing scheme anymore, things worked fine on windows and linux even if we do not update the Geometry.
Then we update the checksum of the VHD, this allows OS to detect potential corruption of the VHD footer.
Step 2 : resize the page blob
Step 3 : clear the old footer and set the new one at the end of the blob
And now, you can enjoy a bigger drive !CodeProject