Category: Azure

New Virtual Machines Series in Azure Dublin / North Europe

I was helping troubleshoot something for a customer today when I noticed that some of the newer VM series have finally arrived in Azure’s Dublin / North Europe region:

  • D_v3: The successor to the D_v2 machines (including the “S” Premium Storage variants) that are designed for disk/database workloads. The machine is 28% cheaper than the RRP of the D_v2, but that’s because it offers VMs on hosts with Hyperthreading … which reduces CPU performance by 28%. Common workloads care more about affordable core counts than GHz, which is what the D_v3 offers.
  • E_v3: The memory-optimized versions (more memory) of the D_v2 are also here, with the same 28% price/GHz reduction.
  • NV: These are machines with direct (not virtualized) access to NVIDIA M60 chipsets on their hosts, specialized for desktop virtualization.
  • NC: You can run virtual machines that are designed for computational workloads (simulations, etc) with these machines, using non-virtualized access to NVIDIA Tesla K80 GPUs.

I’ve just upgraded this server (shutdown – resize  – restart) from a DS2_v2 to a DS2_v3.

FYI, if you are still using the D_v2 promo offer in North Europe, you had better start planning for upgrading to the D_v3 soon if you want to keep that low price. It’s just a matter of time now until Microsoft announces the end of the pre-D_v3 promotion on D_v2 machines, and the price of the D_v2 returns back to normal (28% higher than the promo).

Was This Post Useful?

If you found this information useful, then imagine what 2 days of training might mean to you. I’m delivering a 2-day course in Amsterdam on April 19-20, teaching newbies and experienced Azure admins about Azure Infrastructure. There’ll be lots of in-depth information, covering the foundations, best practices, troubleshooting, and advanced configurations. You can learn more here.

Azure Backup MARS Agent System State Support is GA

Microsoft announced last week that they made support for backing up system state using the MARS agent generally available.

System State backup was one of those “I must have this” features that I’ve been hearing about for 3+ years. Today it’s there – update your version of the MARS agent and you’ll have it.

With this added backup, you can protect metadata:

  • Active Directory: Backup your AD so you can do DC recoveries.
  • File Servers: It’s nice being bale to restore files & folders, but what about the shares?
  • IIS Web Servers: Protect that IIS Metabase.

Adding System State to your backup policy is easy; either start a new schedule (new MARS installations) or edit the existing schedule. System State will appear in the Add Items box. Select System State and complete the wizard. It’s easy … the way backup should be!

Was This Post Useful?

If you found this information useful, then imagine what 2 days of training might mean to you. I’m delivering a 2-day course in Amsterdam on April 19-20, teaching newbies and experienced Azure admins about Azure Infrastructure. There’ll be lots of in-depth information, covering the foundations, best practices, troubleshooting, and advanced configurations. You can learn more here.

Restore An Azure VM to an Availability Set From Azure Backup in the Azure Portal

Microsoft has shared how to restore an Azure VM to an availability set using PowerShell from Azure Backup. It’s nasty-hard looking PowerShell, and my problem with examples of VM creation using PowerShell is that they’re never feature complete.

While writing some Azure VM training recently, I stumbled across a cool option in the Azure Portal that I tried out … and it worked … and it means that I never have to figure that nasty PowerShell out Smile

The key to all this is to start using Managed Disks. Even if your existing VMs are using un-managed (storage account) disks, that’s not a problem because you can still use this restore method. The other thing you should remember is that the metadata of the VM is irrelevant – everything of value is in the disks.

Restore the Disks of the VM

Using these steps you can restore the disks of your VM, managed or un-managed, to a storage location, referred to as the staging account.. Each disk is restored as a blob VHD file, and a JSON file describes the disks so that you can identify which one is the “osDisk”.

Create Managed Disks from the Restored VHDs

In this process, you create a managed disk from each restored VHD or blob file in the staging location. You have the option to restore the disks as Standard (HDD) or Premium (SSD) disks, which offers you some flexibility in your restore (you can switch storage types!). Make sure you ID the osDisk from the JSON file and mark it as either a Windows or Linux OS disk, depending on the contents.

Create a VM From the OS Managed Disk

The third set of steps bring your VM back online. You use the previously restored/identified osDisk and create a new virtual machine using that managed disk. Make sure you select the availability set that you want to restore the VM to.

Clean Up

The last step is the clean up. If you had any data disks in the original machine then you need to re-attach them to the new virtual machine. You’ll also need to configure the network settings of the Azure NIC resource. For example, if the new VM is replacing the old one, you should enter the IP settings of the old VM into the new NIC Azure resource, change any NAT/load balancing rules, NSGs, PIPs, etc.

And that’s it! There’s no PowerShell, and it’s all pretty simple clicking in the Azure Portal that won’t take that long to do after the disks are restored from the recovery services vault.

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.

image

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.

image

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.

image

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!

image

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.

image

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:

image

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.

image

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.

image

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.

image

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.

image

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:

image

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 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.

image

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).

image

I clicked OK, and then powered up the VM.

image