Aidan Finn, IT Pro

Create a New VM From An Existing Managed Disk

In previous posts I have shown how to restore the disks of a VM to a storage account and how to create managed disks from those VHD blobs. In this post, I will show how to create a new VM from a managed disk. When these 3 steps are done together, this is an easy way to restore an Azure virtual machine from backup to an availability set.

I previously created a managed disk from a restored VHD blob, and stored it in a resource group called demorestore. I deliberately named the new managed disk after the VM that I am going to create.

You can only create a new VM from a managed disk that contains an operating system. In the below screenshot, you can see that this disk contains Windows. If this is an OS disk, then you can click the magic button called + Create VM.

What you are doing by clicking the button is shorting the usual Create Virtual Machine blade/wizard. A blade you probably know appears, but some of the features are greyed out because they’re already selected by choosing to create a VM from an existing managed disk.

Enter the name of the new VM, and select the resource group.

In the Size blade, choose the size of the new VM. In settings, choose the availability set (key to restoring a VM to an availability set) and then all the other stuff like network, subnet, extensions, etc.

When you complete the wizard, a VM (which is just metadata) is created using your pre-existing OS managed disk. If you have any data disks to re-use, open Disks in the settings of the VM and add those managed disks with the required host caching mode. And that’s all there is to it!

Microsoft Publishes Some Details on the New Azure B-Series VMs

Last week I blogged about how the pricing of a new B-Series (burstable CPU) virtual machine appeared online. At the time, we knew almost nothing about the machines other than their intended workloads: anything with normally low CPU utilization that could temporarily burst, such as test/dev or low-end web/application servers.

While updating an article for Petri.com, I found that the official specs of Azure VMs had been updated to include the B-Series:

The B-Series provides these customers the ability to purchase a VM size with a price conscience baseline performance that allows the VM instance to build up credits when the VM is utilizing less than its base performance. When the VM has accumulated credit, the VM can burst above the VM’s baseline using up to 100% of the CPU when your application requires the higher CPU performance.

That means that this is very similar to the AWS T2 Instances. By default, your machine’s CPU is artificially capped. By underutilizing the CPU, the machine can earn & bank credits that can be later used. This bank has a hard limit, depending on the size of the machine. Should the service in the machine need more CPU, those credits can be burned to go beyond the artificial cap to use the underlying physical cores potential. In other words, the less you use the CPU, the more horsepower you get for those times when you need it.

Here are some details on the sizes in the B-Series.

All of the machines are S-variants
Each machine has a small amount of SSD temporary storage.
Note how the disk stats refer to “max local disk”. Hmm!

Right now, there is a limited access preview for the B-Series in just a few regions:

West Europe
West US 2
East US
Asia Pacific – Southeast

I can see the B-Series in my subscriptions, but I cannot deploy it – the quota is set to 0 and the blade for requesting an increase does not include the B-Series. I guess this is still a private preview for now, and things might change on Sept 25th (Ignite).

Create an Azure Managed Disk from a VHD Blob

This post will show you how to create a managed disk from a VHD blob file, such as one you’ve uploaded or restored from a virtual machine backup. In my example, I have restored the virtual hard disks of an Azure VM to a storage account called aidanfinnrestore. I am going to create a new managed disk from the VHD blob, and (in another post) create a new VM from the managed disk that I am creating in this post.

Open the Azure Portal, and go to Disks in the navigation bar on the left – this is where all managed disks are listed. Click + Add. A Create Manage Disk blade appears. Enter the following information:

Name: Give the new managed disk a name. My naming standard names the disk after the VM with a suffix to denote a role. In my example, it’s an OS disk.
Subscription: Select the subscription in your tenant. Note that you must create the managed disk in the same subscription as the storage account that contains the blob – you can always move the disk to a different subscription later.
Resource Group: Restore the disk to a new or existing resource group – typically this is where the virtual machine will be.
Location: Pick the region of the desired VM, which must also match the storage account.
Account Type: What kind of managed disk do you want – Standard (HDD) or Premium (SSD). You can change this later, one of the nice features of managed disks.
Source Type: I have selected Storage Blob – this is how the restored (or uploaded) VHD is stored.
Source Blob: Click browse, and navigate to & select the VHD blob that was restored/uploaded.
OS Type: If this is a data disk then select either Windows or Linux, depending on the guest OS in the VHD.
Size: To make like easy, select the size of the existing blob. I restored a managed disk to a blob, so I went with the original size of 128 GiB.

Once you’re happy with all the settings, click Create. In my case, with a 128 GiB VHD, the creation just around 30 seconds:

Now you can either create a VM from the disk or attach it as a data disk to an existing VM in the Azure Portal – life is easy with managed disks!

Restore an Azure Virtual Machine’s Hard Disks

In this post, I’ll show you how to restore just the disks of an Azure virtual machine. This is useful if you want to restore a virtual machine to an availability set, or restore it as a different series/size.

Restoring to Availability Sets

For some reason that I do not know, we cannot restore a virtual machine to an availability set in Azure. It probably has something to do with the restriction in ARM that prevents a VM from being able to join an availability set after creation (vote for change here).

As a workaround, Azure Backup allows you to restore the disks, and then use those disks to create a new virtual machine (metadata) that is joined to the availability set. On the official docs pages, there is some pretty messy looking PowerShell to re-create the VM from those disks.

Thanks to some features of Managed Disks, if you have used managed disks for the VM, then you don’t need to go anywhere near that nasty PowerShell or JSON! I’ll post about that soon.

Restoring Disks

Browse to to the recovery services vault, open it, go to Backup Items > Azure Virtual Machine, and select the VM in question. Below is a screenshot of my web server in Azure. Click Restore VM.

A blade with recovery points appears. Choose a restore point, i.e. a point in time from when you want to restore from, and click OK.

The Restore Configuration blade appears. Choose Restore Disks as the Restore Type, and choose a storage account as the Staging Location. Click OK to start the backup job.

Some time later, the disk(s) of the virtual machine are restored as blobs in a container in the storage account. You’ll also find a JSON file with details of the disk(s) that were restored.

By the way, if you cannot tell which of the VHD blobs is your OS disk, download the JSON file and open it in Notepad (VS Code refuses to open it for me). The “osDisk” setting will tell you the path of the VHD blob that was the original data disk.

Microsoft’s solution would have you restore the virtual machine using PowerShell and that JSON file. I’ve read through it – it’s not pretty! My solution, in a later post, would create managed disks from the VHD blob(s), and then create a VM from the OS disk … and that’s nice and easy using the Azure Portal and a few mouse clicks.

Azure Low Cost “Burstable” CPU Virtual Machines

Microsoft has released pricing for a new kind of virtual machine in Azure, called the B-Series. The key traits of this VM type are:

It is 1/4 the price of a similar A_v2-Series machine.
The CPU runs at a low rate, and “bursts” on demand for higher capacity jobs.

I’d love to have more information to share, but all we have is all I stumbled upon in the pricing pages last week:

As you can see in the names, they comply with the “new” format. That S in the names suggests that these machines support Premium (SSD) storage disks.

These are low end machines, as you can see by the entry level 1 core & 1 GB RAM model. The Microsoft VM pricing page says that they are good for:

… development and test servers, low traffic web servers, small databases, micro services, servers for proof-of-concepts, build servers, and code repositories.

The costs are really low. The B2S is just €20.71 per month, compared with €85.33 for the A2_v2 – both having 2 cores and 4 GB RAM. If you want a low end web server, then that’s a seriously cheap offering!

AWS does have something called T2 Instances. These are VMs that offer CPU burst-ability based on credits earned for low CPU utilization. The rough language of suitable roles is similar to that of the Azure B-Series. However, we have no detailed information on the B-Series yet – my bet is that will be published on September 25th (Ignite day 1).

Azure VM Could Not Start–Missing Boot Diagnostics Storage Account

I recently had an issue where starting an Azure virtual machine would fail. The reason given was that the Boot Diagnostics storage account was missing. In this post, I’ll show you mu workaround.

As part of my recent upgrade/migration for the VM hosting this site, I did a big clean up and re-organization of resources. One piece of that was to deploy a dedicated storage account for diagnostics and logging. I configured the VM Agent to use this new diagnostics storage account, and I changed Boot Diagnostics to use this new diagnostics storage account too – both updates appears to succeed because the notifications said the changes were successful. I then deleted the old storage account because it was no longer used.

Later in the day, I shutdown the VM to resize it. Then I attempted to boot the VM up, and the start job failed. That caused an increase in my heart’s BPM! I explored the error and it said that the storage account for Boot Diagnostics could not be found.

FYI, boot diagnostics periodically captures a BMP file of a Windows Server VM’s “console” and stores it in a container in the storage account. I don’t like that failing to get a screenshot fails a VM.

I checked Boot Diagnostics, and … the old storage account that I had replaced and deleted was still specified. I changed it to the new storage account, and saved the change. Once again, I got a notification that the save was successful.

I attempted to start the VM again, and I got the same error. I went back into Boot Diagnostics, and the old storage account was still specified. I’d see this happen before and I new how to work around it:

Disable Boot Diagnostics in the VM and save the change.
Start the VM – now it will start.
Enable Boot Diagnostics in the VM, select the new storage account, and save the change.

This gets the VM running as quickly as possible, and gets Boot Diagnostics to use the correct storage account.

Azure VM Sizes Missing When Resizing

When you are resizing a running virtual machine, you might find that many sizes are not available. There is a workaround – shut the VM down! Here’s how I resized the Azure virtual machine that hosts this site, which started the day as an A2_v2 virtual machine.

First, I powered down the VM in the Azure Portal. Then I browsed to Size. All of the possible sizes were presented to me then. I selected a DS2_v2 Promo size, knowing that the price will increase to normal DS2_v2 pricing once the D3 is live in North Europe (I’ll upgrade then).

I clicked OK, and then powered up the VM.

How I Upgraded This VM To Azure Resource Manager

In this post, I will explain how I upgraded the Azure virtual machine, that this site is hosted on, from ASM (Azure Service Management, Classic or Azure v1) to ARM (Azure Resource Manager, Resource Manager or Azure v2).

FYI, although I had no plans for changing subscriptions, this migration is also the first step for moving resources from one subscription to another, e.g. Credit Card/Direct to CSP, Open to CSP, or EA to CSP.

Background

I’ve been running aidanfinn.com on Azure for a few years now. It game me a vested interest in Azure, other than my day job where I teach and sell Azure services to MS partners. Over the years, I’ve applied some of the things that I’ve learned, including one time where MySQL blew up so bad that I had to use Azure Backup (then in preview) to restore the entire VM – this is why you’ll see the phrase “aidanfinn02” later in the example.

The VM was running in ASM. ASM is effectively deprecated, but I never had a chance to migrate it to ARM. That changed, and I decided to make the switch. In the process, I decided that I wanted to clean up resource groups, migrate to managed disks, and maybe change a few other things.

I had two options available to me:

MigAz: Great community tool that allows a complete change, including renaming. There is downtime to move the disks.
The “Platform Supported” method: Using official cmdlets to do an ASM-ARM migration with no downtime during the ASM-ARM migration.

I went with the platform supported method. Long-term, it means I have more work to do to do some renaming, etc, but I’ve never had “my own” stuff to move using this method, so I wanted to do it and document it with a real example.

Note that the platform support method has a few approaches. My virtual machine was in a virtual network, so I opted to move the entire virtual network and associated contents. This is cool because, all VMs (I have one only) are moved, and endpoints are converted into NAT rules in a load balancer. Any reserved cloud service IPs are converted into static public IPs.

Note, you’ll need to download the latest Azure PowerShell modules (and reboot if it’s your first install) to do either method.

FYI, the below includes copy/pastes of the actual cmdlets that I used. The only thing I have modified, for obvious reasons, is the subscription ID.

Register the Migration Provider

You’ll need to register the provider that allows you to do ASM-ARM migrations. This is done on a per subscription basis. You’ll log into your subscription using ARM:

Login-AzureRmAccount

If your tenant has more than one subscription, like mine does, then you need to query the subscriptions:

Get-AzureRmSubscription

This allows you to get the ID of the subscription that you will sign into, so you can select it as the current subscription to work on:

Select-AzureRmSubscription -SubscriptionId 1234567f-a1b2-1234-1a2b-1234ab123456

Next you register the migration proivder:

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

This migration can take up to five minutes. You can query the status of the migration:

Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

You can continue once you get a registered status:

ProviderNamespace : Microsoft.ClassicInfrastructureMigrate

RegistrationState : Registered

ResourceTypes : {classicInfrastructureResources}

Locations : {East Asia, Southeast Asia, East US, East US 2…}

Validation

The migration has three phases. The first allows you to validate that you can migrate your machines cleanly. Common issues include unsupported extensions, extension versions, classic backup vault registrations, endpoint ACLs, etc.

To do the validation, you need to sign in using ASM:

Add-AzureAccount

Once again you need to make sure you’re working with the right subscription:

Get-AzureSubscription

And then make that subscription current:

Select-AzureSubscription -SubscriptionId 1234567a-a1b2-1234-1a2b-1234ab123456

I migrated my virtual network, so I queried for the Azure name of the virtual network.

Get-AzureVnetSite | Select -Property Name

My virtual network was called aidanfinn02 so I saved that as a variable – it’ll be used a few times.

$vnetName = “aidanfinn02”

Then I ran the validation against the virtual network, saving the results in a variable called $validate:

$validate = Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName

I could then see the results:

$validate.ValidationMessages

There were two issues:

A faulty monitoring (Log Analytics) extension (guest OS agent)
The VM was being backed up by a classic Azure Backup backup vault.

ResourceType : VirtualNetwork

ResourceName : aidanfinn02

Category : Error

Message : Virtual Network aidanfinn02 has encountered validation failures, and hence it is not supported for migration.

VirtualMachineName :

ResourceType : Deployment

ResourceName : aidanfinn02

Category : Error

Message : Deployment aidanfinn02 in Cloud Service aidanfinn02 has encountered validation failures, and hence it is not supported for migration.

VirtualMachineName :

ResourceType : Deployment

ResourceName : aidanfinn02

Category : Error

Message : VM aidanfinn02 in HostedService aidanfinn02 contains Extension MicrosoftMonitoringAgent reporting Status : Error. Hence, the VM cannot be migrated. Please ensure that

the Extension status being reported is Success or uninstall it from the VM and retry migration.,Additional Details: Message=This machine is already connected to another

Log Analytics workspace, please set stopOnMultipleConnections to false in public settings or remove this property, so this machine can connect to new workspaces, also

it means this machine will get billed multiple times for each workspace it report to. (MMAEXTENSION_ERROR_MULTIPLECONNECTIONS) Code=400

VirtualMachineName : aidanfinn02

ResourceType : Deployment

ResourceName : aidanfinn02

Category : Error

Message : VM aidanfinn02 in HostedService aidanfinn02 contains Extension MicrosoftMonitoringAgent reporting Handler Status : Unresponsive. Hence, the VM cannot be migrated.

Please ensure that the Extension handler status being reported is Ready or uninstall it from the VM and retry migration.,Additional Details: Message=Handler

Microsoft.EnterpriseCloud.Monitoring.MicrosoftMonitoringAgent of version 1.0.11049.5 is unresponsive Code=0

VirtualMachineName : aidanfinn02

ResourceType : Deployment

ResourceName : aidanfinn02

Category : Error

Message : VM aidanfinn02 in HostedService aidanfinn02 is currently configured with the Azure Backup service and therefore currently not supported for Migration. To migrate this

VM, please follow the procedure described athttps://aka.ms/vmbackupmigration.

VirtualMachineName : aidanfinn02

The solutions to these problems were easy:

I signed into the classic Azure Management Portal and unregistered the virtual machine in the backup vault – DO NOT DELETE THE BACKUP DATA!
Then I switched to the Azure Portal (and stayed here), and I removed the VMSnapshot (Azure Backup) extension from the VM.
And then I removed the Microsoft.EnterpriseCloud.Monitoring (Log Analytics) extension
The VM had an old version of the Diagnostics agent, so I removed that too, even though it didn’t effect validation.

I re-ran the validation:

$validate = Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName$validate.ValidationMessages

And the result was that the virtual network (and thus the VM) was ready for an ARM migration.

$validate.ValidationMessages

ResourceType : VirtualNetwork

ResourceName : aidanfinn02

Category : Information

Message : Virtual Network aidanfinn02 is eligible for migration.

VirtualMachineName :

ResourceType : Deployment

ResourceName : aidanfinn02

Category : Information

Message : Deployment aidanfinn02 in Cloud Service aidanfinn02 is eligible for migration.

VirtualMachineName :

ResourceType : Deployment

ResourceName : aidanfinn02

Category : Information

Message : VM aidanfinn02 in Deployment aidanfinn02 within Cloud Service aidanfinn02 is eligible for migration.

VirtualMachineName : aidanfinn02

Preparation

The preparation phase is next. This is an interim or trial period where you introduce the ARM API to your resources. For a time, the resources are visible to both ARM and ASM. There is no downtime, but you cannot make any configuration changes. The reasoning for this is that you can validate that everything is still working.

You run the command, as I did against the virtual network.

Move-AzureVirtualNetwork -Prepare -VirtualNetworkName $vnetName

And then you wait … try not to grind your teeth or chew your gums:

OperationDescription OperationId OperationStatus

——————– ———– —————

Move-AzureVirtualNetwork 2bcb56ce-2330-0824-a376-a3dcc4892e3d Succeeded

Commit

Once preparation is done, double-check everything. My website was still responding, and resources appeared in two different resource groups with -Migrated suffixes – I’ll show you how I tidied that up later in the post. I was ready to commit; this is when you tell Azure that all is good, and to please remove the ASM APIs from the resources.

Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName

More time passes when you forget to breath, and then it’s done! You’re in ARM, and your resources are manageable once again. Note that there is an alternative to Commit, which is to abort the process and roll back to ASM-only management.

Network Security Group

My ASM deployment was quite basic, and not best practice. I created a network security group for the subnet, allowing in:

RDP to the subnet
HTTP to the local static IP of the VM.

Resource Group Clean-up

As I mentioned, my ASM resources migrated into two resource groups as ARM resources. I wanted to:

Move the resources into a single resource group.
Get rid of the –Migrated suffix.

You can move resources, but you cannot rename resource groups. So I created a third resource group (aidanfinn):

Then I moved the resources from both of the migrated resource groups into the new aidanfinn resource group:

Migrate Storage to ARM

The official method for migrating storage is to migrate the storage account. That means that you move the storage account with the VHDs within it. Azure offers a new method for handling storage called managed disks:

You dispense with the storage account for VHDs
The disk becomes a manageable resource in the Portal
You get cool new features like Snapshots and easier VM restores from disk

I decided to take a different route – I would convert my ARM VM from un-managed disks to managed disks. I needed a few values:

$rgName = "aidanfinn"
$vmName = "aidanfinn02"

I stopped the VM (my first piece of downtime in this entire process):

Stop-AzureRmVM -ResourceGroupName $rgName -Name $vmName -Force

Then I did the conversion:

ConvertTo-AzureRmVMManagedDisk -ResourceGroupName $rgName -VMName $vmName

And then I restarted the VM, after just a few minutes of downtime:

Start-AzureRmVM -ResourceGroupName $rgName -Name $vmName

Re-Introduce Management

I like the management features of Azure, so I re-introduced:

Azure Backup of the VM using a recovery services vault using a custom policy – I created a manual backup immediately.
Monitoring & diagnostics, to a new dedicated storage account – make sure you verify that the storage account is being used by the VM Agent and Boot Diagnostics.

Cleanup ASM

Lots of stuff can get left behind, especially if you’ve been trying things out. That all needs to be removed. One thing I kept around for a while was the classic backup vault, just in case. I only unregistered the old ASM VM – I did not delete the data. That means I have a way back if all goes wrong in ARM or I screw up in some way. I’ll give it a month, and then I’ll remove the old vault.

By the way, you can upgrade a backup vault to ARM (recovery services vault) if you want to keep your retention.

The End Result

I ended up with everything in ARM and in one resource group:

I don’t like the naming, so I will be cleaning things up. My next mini-project will be to:

Power down the VM.
Create a disk snapshot.
Create a new disk from the snapshot.
Create a new deployment, using the new disk, with names that I like.

I know – I could have done all that more quickly and easily using MigAz, but I wanted to do the platform supported migration on my stuff, and it was a chance to document it too! Hopefully this will be useful for you.

Inspire 2017 Day 1 Keynote

What We Know So Far

There’s been lots of talk and sharing about Azure Stack. Lenovo and HPE have opened up orders. Microsoft has also announced availability of the Azure Stack Development Kit, the free single-server deployment (what we saw in the Preview program).

A DJ is DJ-ing on a Surface Studio and tells us to turn off our phones. And now we get an inspirational video on MS and Washington. Then someone talks about mountain climbing and dreams and stuff.

Ron Puddleston – One Commercial Partner VP

Over 17,000 people at the keynote – or trying to get in because security is supposed to be creating a nightmare there. Lots of “partners are great” and “partners are great”.

Partner feedback, according to him, was the MS wanted one way to be in contact with MS, and one way to interact with customers. They wanted one voice to advocate for them. And that’s why MS created “One Commercial Partner” group from SMS&P, EPG and other organizations last week. It’s to be “partner first”. It’s supposed to be simple and aligned to how partners work:

Build the business
Go to market
Sell with partners to customers

That’s supposed to be what OCP (sounds like Robocop) does. They are measured on partner growth, not individual product sales. They’re investing €250,000,000 to connect partners with customers. The GM is to connect partners to customers – this is not a partner account manager as the past. He says “the right partner for the customer” – big emphasis this FY by Inside Sales on partners with competencies. Two new things:

Focus on Azure billed revenue caused frictions for partners. Azure consumed revenue is now the goal. That only affects EA customers because they’re the same in CSP.
MS reps will be recognized for 10% of the value of co-sold ISV products.

One partner team will offer all this.

Satya Nadella

He says the partner conference sets the tone for the rest of the MS financial year – it’s a highlight for him. 140 countries represented at the conference. There are currently 17 million jobs around the world because of MS partners. There are 64,000 partners leading with cloud solutions. Partners coming into the MS cloud from other ecosystems: Linux, Hadoop, Java.

They’ve been talking about mobile first/cloud first for years and been getting loads of feedback from MS partners’ digital transformation stories. Moving towards Intelligent Cloud/Intelligent Edge. 3 characteristics:

Every experience that is built is multi-device and multi-sense. Might be speech on one, ink on another, touch on another.
Infusion of AI – in every application experience that will be built. An autonomous car will generate 4 GB of data per second. That’s one car per second. That data has “gravity”. AI is being distributed to devices, not just in data centres.
Managing all of this complexity requires a new efficient frontier for application development, distribution and management. This is about serverless tech, such as containers, functions, logic apps, etc.

The opportunity is bigger than ever before and growing. Microsoft has a history of jumping on platform shifts. The PC was democratized. Then client/server. There is $4.5 trillion of spend here. The product and the service are digital.

We will all thrive if we do the above by geography and by industry. Modern Workplace, etc above, are the framework.

Modern Workplace is where he starts. Empower people inside of your organization – brings a shift in culture and the early signal of digital transformation. Lots of CEOs in a video about changing business to be self-empowered, nimble, competitive, creative, etc.

The demographics of the workplace are changing. Skills are changing. How teams come together is changing. Teams are dynamic, traditional IT is not. Bring the systems into one simple framework. Need sophistication to protect the many endpoints for user access and data flow. Need operational insight to detect and respond to attacks.

Microsoft 365

Coming together of Office 365, Windows 10, and EMS. Two offerings: Enterprise (was Secure Compute Enterprise SKU) and Business (for SMEs).The 4 pillars are:

Creativity
Teamwork
Simplicity
Security

Demo coming up. Sonia Dara starts with an iPhone-base demo.

I had to leave at this point for a customer Skype call … interesting timing

Upcoming Webinar: 4 Important Azure IaaS features for building your Hybrid Cloud

I’m going to be presenting in a webinar by Altaro on July 18th. It’s an interesting topic, Azure, because lots of IT pros are wondering if/how they’ll use Azure and how they should get started. As an IT pro, your first ventures into The Cloud will probably be infrastructure, so I’ll talk about a few topics that will hopefully get you better prepared.

Altaro has a big audience around the world, so the webinar will be run twice:

Time for EU attendees: (2pm CEST)
Time for US attendees: (10am PDT / 1pm EDT)