Hide-and-seek with Cloud Services containers for Virtual Machines on Azure

From several conversations I had recently it transpired that there’s some confusion around the relevancy of Cloud Service when using Virtual Machines on Azure.
Initially it surprised me, but then it was pointed out to me that, in fact, the Windows Azure Management Portal does a very good job festering this confusion.

I’ll get to why in a moment but first let me start with this –

The simplest way to think about how a Virtual Machine is deployed to Azure is the good-old VM Role –

Just as the VM Role used to, a Windows Azure Virtual Machine is deployed as a role with a single instance within a cloud service. This is quite apparent when you look at it in the old portal – here’s an example of a VM I created in the Management Portal using the standard quick-create as seen on the old portal –

image

Ok – there’s plenty behind the scenes that the platform is doing differently when managing VMs vs. Web or Worker roles, but from a deployment model point of view, a cloud service is created with a single instance of a role which happens to be a Virtual Machine.

So – why is the portal confusing? well – because, and I suspect that it was an attempt to simplify things that ended up making things rather more confusing – when you deploy a VM, the management portal chooses to hide it’s existence –

I’m guessing that the thinking was that with a single VM the cloud service is rather irrelevant – conceptually, the role and the instance are one and all the management operations and monitoring are done at an instance level and so – there was no real need to surface the fact that a cloud service exists.

Unfortunately, things start to get more confusing as soon as you delete your VM because at some point during the delete operation, the corresponding Cloud Service will suddenly appear, and eventually, when the delete operation will complete, it will be empty –

image

It appears largely for one reason – so that it can be deleted; otherwise a phantom service will remain in the subscription with no way to manage it through the UI.
BTW – the API and Powershell (and some dialogues, as you will see shortly), seem to always reveal the real details, and the cloud service that is clearly visible in the old-portal is also fully accessible through these. In fact – the description given to the cloud service says it all –

image

So – why the platform, which had kindly created this cloud service for me – doesn’t also kindly remove it? well – I suspect that this is because it cannot assume that the container will only contain the original VM. How come? let’s look at another case when the cloud service suddenly appears –

If you deploy a second VM, from Gallery, and choose to connect to an existing virtual machine –

image

(notice how the non-existent cloud service suddenly makes an appearance?)

What you are actually requesting the platform to do is to deploy an new instance, of a new role, into the same cloud service, and that’s a whole different story!  Now – not only the cloud service has a meaning that is greater than either VM definitions, deleting the first VM clearly cannot delete the cloud service and so – shortly after requesting the second VM – the cloud service will make it’s formal appearance in the portal –

image

and again – looking at how things look like in the old portal can help get a somewhat clearer behind-the-scenes view – one service, two roles, one instance of each –

image

In the new portal, this is reflected like this (which isn’t telling the full story) –

image

Interestingly, although not wholly surprisingly, removing the second VM does not re-hide the cloud service and so it is possible to ‘see in the wild’ a Cloud Service with a single VM in it –

image

And so – given this seemingly erratic behaviour, even if there is some method behind the madness, it is not surprising the people get confused.
Personally, I would have much preferred if things were straight forward, black and white – you create a VM, you get the corresponding Cloud Service. Simples.

But there you go – nobody asked me, so at least I hope this helps shed some light on the subject

Side note – all of this also helps explain the very long and repetitive names given to disks – the naming convention is [cloud serivce]-[VM name]-[disk number]-[timestamp]

Advertisements

Backing up a Windows Azure Virtual Machine using PowerShell

Back in June I wrote about how to use snapshots to backup and restore VHDs used by Windows Azure Virtual Machines.

Whilst this approach does have the limitation of only copying the state persisted to the disk and so I would not recommend using it on running VMs, for cases when the VM can be shut-down temporarily this can be a handy approach.

This could be particularly useful for dev and test scenarios when the VMs can be turned off and when users of those VMs might want to be able to go back to various known states.

Of course doing the whole process manually is cumbersome, time consuming and error prone, so scripting is needed and so in this post I’ll show what it takes to do this using PowerShell

‘Backing up’ a virtual machine using snapshots

The first job would be to turn off the virtual machine we want to back-up

Stop-AzureVM -ServiceName $cloudSvcName -Name $vmname

With the VM stopped it is time to take the snapshot. unfortunately the Azure PowerShell Cmdlets do not, currently, support snapshot operations on Blobs but thankfully Cerebrata have produced a great set of Cmdlets for Azure Mananagement

Taking a snapshot of a Blob using the Cerebra Cmdlets is very easy –

Checkpoint-Blob -BlobUrl $blobUrl -AccountName $accountName -AccountKey $accountKey

It is worth noting that this command returns the url for the snapshot, and it might be useful to keep for later use. Also worth noting is that it is possible to add metadata to the snapshot, in the form of a collection of key-value pairs, which could be used to select snapshots later, finally it is useful to know that this command is pretty much instantaneous  so whilst there’s some downtime required for shutting down and starting up the machine, taking the snapshot takes no time at all.

With the snapshot taken it is now time to start our VM again

Start-AzureVM -ServiceName $cloudSvcName -Name $vmname

and so, with a very short powershell script, one can create an effective backup of a virtual machine which will be stored with the Blob. It is worth noting again that this is only reliable when the machine is stopped (turned off) before the snapshot is taken. it is also worth noting that if machines may have more than one disk and additional disks may need to be handled too (in the same way)

‘Restoring’ a virtual machine using snapshots

Restoring a VM is a little bit more involving – when a disk is attached to a VM a lease is created on the Blob storing the disk effectively locking it for everyone else.

That means that one has to remove the VM before a snapshot can be ‘promoted’ on a VHD (effectively overwriting the blob with the snapshot), stopping the VM would not be enough, and so to start we do have to stop the VM again, as before –

Stop-AzureVM -ServiceName $cloudSvcName -Name $vmname

but in order to update the OSDisk we also need to remove it completely.

Before we do that, given that we’re going to bring it back online shortly, it would be useful to export all of its configuration first –

Export-AzureVM -ServiceName $cloudSvcName  -Name $vmname  -Path 'c:\tmp\export.xml'

and with the VM configuration exported, we can go ahead and remove it

Remove-AzureVM -ServiceName $cloudSvcName -Name $vmname

Now that the machine is gone, its lease on the blob is gone too, which means we should be able to use Cerebrata’s Copy-Blob Cmdlet to copy the snapshot over the Blob

Copy-Blob -BlobUrl $blobUrl -TargetBlobContainerName $container -AccountName $accountName -AccountKey $accountKey

Like the Checkpoint-Blob command this is pretty much instantaneous.

Now that we have the updated disk in place, it’s time to bring our VM back to life, first import –

Import-AzureVM -Path 'c:\tmp\export.xml' | New-AzureVM -ServiceName $cloudSvcName -Location 'North Europe'

and that is it – when the VM creation, using the imported configuration, completes – we have our VM back online this time running off the updated VHD state

Final note – in this post I just wanted to show the key operations one would use to create a useful script. the actual process will vary depending on the specific requirements and , of course, it is possible  to make quite an elaborate script with PowerShell – for example it is possible to enumerate on all the VMs in a particular cloud service and for each VM query the OS and Data disks and then perform all the operations above over these enumerations, the sky is pretty much the limit! 🙂

%d bloggers like this: