Over the weekend, one of my Azure VMs went down. The first indication was that it showed up in SCOM 2012 (SP 1 Beta) as missing it’s heartbeat. RDP from on premise, and from another VM on the Azure virtual network failed.

I went thru some of my normal trouble shooting steps, which a lot of times feel like a crap shoot with Azure VMs. First I tried restarting the VM from the management portal. While this succeeded, I was still unable to connect. I also tried changing the VM size which sometime helps because it  causes the VM to be redeployed. This also did not work.

That left me with the semi-nuclear option of deleting the VM. Remember that deleting the VM, does not delete the disks (full nuclear option). Dropping down to power shell I:

• Stopped the VM: Stop-AzureVM -ServiceName 'ServiceName' -Name 'Name'
• Deleted the VM: Remove-AzureVM -ServiceName 'ServiceName' -Name 'Name'
• Deleted the Service: Remove-AzureService -ServiceName 'ServiceName'

Deleting the service is somewhat optional, and I could have tried to deploy the VM to the existing service, which would have preserved my internal IP address.

To create a VM using existing disks, you still using the New-AzureVMConfig cmdlet, but you specify the OS disk using the –DiskName parameter. This is not the Blob URL, but the name of the disk as it is defined in the Azure VM disk repository (remember that each disk is created as a blob, and then registered in the disk repository). When you specify the –DiskName parameter, you no longer have to specify a provisioning configuration (i.e. Windows, Windows Domain or Linux). You can also attach additional disks, using the –Import parameter of Add-AzureDataDisk. Here is an example of my script I used to create a new AzureVmConfig, which is then passed to New-AzureVM.

$vmI1 = New-AzureVMConfig -Name MachineName -InstanceSize Small -AvailabilitySetName 'Whatever' -DiskName 'MachineName-System' |

Add-AzureDataDisk -Import 'MachineName-Data01' -LUN 0 |
Add-AzureDataDisk -Import 'Machine-Backup' -LUN 1 |
Set-AzureSubnet SubnetInternal

Of course nothing is ever easy, and when I executed my script, I got an error stating that the blob had an existing lease.

A lease conflict occurred with the blob

Thankfully, this was an easy google/bing fix as my first search hit yielded a post on the Windows Azure Virtual Machines for Linux forums. Since I had PowerShell installed, I opted to use the break lease power shell script that was provided. While the output of this script indicated that the blob had a lease, and that the lease had been removed, I still got the same error.

Going back to the forum post, I next followed the suggestion to remove the disk from the VM disk repository, and then re-add it. While I’m not sure if I would have been able to do this without first breaking the lease, it worked none-the-less and I was able to re-create my VM.