Set-AzureSubscription from a publish file

IaaS Management Studio generates powershell script for everything you do.

Most operations on VMs start like that

$cert64 = [System.Convert]::FromBase64String("#Base64 of the certificate....")
$cert = New-Object 'System.Security.Cryptography.X509Certificates.X509Certificate2' $cert64, ""
Set-AzureSubscription -SubscriptionName "AO-IS Bizpark" -SubscriptionId "a26aaa6a-e02a-2746-9140-4bdca437f224" -Certificate $cert -ServiceEndpoint https://management.core.windows.net/

This allows the make the script runnable everywhere with simple copy/paste without any other deployment.

If you are using the free version, or you are adjusting the code for your own scripts, then you will prefer to create a subscription from a publish setting file downloaded from Azure Portal, so here is an alternative version to do the exact same thing from a publish file.

Set-AzureSubscription –SubscriptionName “Subscription from publishsettings” –SubscriptionDataFile “account.publishsettings”

As a reminder, you can get your publish settings file by going to following link : https://manage.windowsazure.com/publishsettings/index

How VHD resizing works ?

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.

image

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.

image

Step 2 : resize the page blob

image

Step 3 : clear the old footer and set the new one at the end of the blob

image

And now, you can enjoy a bigger drive !