Azure Managed Disks

Contents
×
  1. Overview
  2. Key features
  3. Key concepts

Key concepts

Now that you have an initial understanding of the Azure Managed Disks service, let’s spend some time going through all the different components and features in detail.

Disk roles

In Azure, disks play three primary roles:

  • Operating system (OS) disk An OS disk is created by default for every VM you create in Azure. This disk contains the OS running on the VM as well as the boot volume. The OS disk supports partitioning with a master boot record (MBR) and GUID partition table (GPT) depending on the OS requirement. By default, most operating systems use partitioning with MBR, which limits the OS disk capacity to 2 TB. However, you can increase this to 4 TB by converting the disk from MBR to GPT.

  • Temporary disk Microsoft provides a temporary disk as a non-persistent disk for specific VM models in Azure. When selecting the VM size in Azure, you can see the size of the temporary disk provided with that VM type. Any data you store on the temporary disk should be data that you are willing to lose, such as page files, swap files, or temporary logs. Each time a VM undergoes a forced restart, maintenance, or a redeployment, data on the temporary disk is erased. The VM can retain data stored on these disks only during standard reboot operations. Temporary disks are not encrypted by default, although you can enable encryption if needed. These disks are mapped as D: in Windows VMs and /dev/sdb in Linux-based VMs.

  • Data disk Data disks are optional, and you can use them based on your workload requirements—for example, separating database installation files from data and log files, which can be stored on their own or individual data disks. As mentioned, OS disks have a maximum capacity of 4 TB, so any data-storage requirements that exceed that would require you to use data disks. The maximum disk capacity for a single data disk is currently 32,767 gigabytes (GB) for Standard HDD, Standard SSD, and Premium SSD disks. However, Ultra disks can be scaled up to 65,536 GB. The number and type of data disks that you can use with a VM depends on the size and type of the VM. Be sure to consider this when selecting the size for your VM.

NOTE

Every VM has an OS disk. Whether a VM has a temporary disk depends on the VM model. Data disks are optional based on your workload requirements.

Disk types

Azure offers four types of disks:

  • Standard HDD disks

  • Standard SSD disks

  • Premium SSD disks

  • Ultra disks

Standard HDD disks

Standard HDD disks are suitable for workloads that are less critical and are not latency sensitive and for dev/test environments. These disks provide write latencies of less than 10 milliseconds (ms) and read latencies of less than 20 ms. Their performance varies depending on numerous factors, including IO size and workload pattern. Standard HDD disks are the least expensive (per gigabyte) disk option in Azure.

Standard SSD disks

Standard SSD disks are a great alternative for customers that want better performance, scalability, availability, and reliability than is possible with Standard HDD disks. Standard SSD disks are a great choice for low-intensity workloads that require consistent performance, such as web servers, low-usage business applications, and low IOPS applications. Standard SSD disks of 512 GB or more support credit-based bursting, making them ideal for applications that require a burst of performance only on rare occasions. All Azure VMs support Standard SSD disks.

Premium SSD disks

Premium SSD disks offer the second highest level of disk performance, with single-digit millisecond latencies, targeted IOPS, and defined throughput 99.9% of the time. They are suitable for high-intensity workloads, such as production applications and databases.

Premium SSD disks come in different sizes, and the level of IOPS support differs depending on the size of the Premium SSD disk. For example, P1 4 GB to P4 32 GB disks provide 120 IOPS, P10 128 GB disks provide 500 IOPS, while P80 32 TB disks provide 20,000 IOPS. Disk throughput and burst performance also increase as the capacity of the Premium SSD disks go up.

A few more features of Premium SSD disks are as follows:

  • Premium SSD disks support one-year reservations to help you save on costs. You can set reservations for disks 1 TB and larger.

  • Premium SSD disks support on-demand and credit-based bursting models. Bursting enables the Premium SSD to increase its performance in the short term to meet workload requirements.

  • Only specific Azure VM types support Premium SSD disks. When you select a VM type, Azure shows you which types of disks that VM type supports. Because Microsoft adds and removes VM SKUs on an ongoing basis, I have not listed the VM types here, because they may change by the time you read this.

Ultra disks

Ultra disks currently provide the highest level of performance in terms of IOPS and disk throughput, with sub-millisecond latency 99.99% of the time. This makes Ultra disks suitable for critical high-performance workloads such as SAP HANA, mission-critical databases, and transaction-heavy applications.

By default, each Ultra disk can be scaled up to 32 TB. However, you can contact Azure support to request an increase of up to 64 TB. In terms of IOPS, each Ultra disk supports a minimum of 300 IOPS per gibibyte (GiB) and currently maxes out at 160,000 IOPS per disk.

Ultra disks allow you to adjust IOPS and throughput performance during runtime. You are permitted four adjustments every 24 hours. Each adjustment can take up to one hour to take effect and requires sufficient performance bandwidth capacity to prevent failures.

At present, Ultra disks have numerous limitations. These include lack of support for the following:

  • Availability sets

  • Azure Dedicated Host

  • Disk snapshots

  • Azure Backup

  • Azure Site Recovery

  • Disk exports

  • VM image creation

In addition, Ultra disks cannot be used as OS disks. They can only be set up as data disks. For high-performance workloads that call for the use of an Ultra disk, you will want to set up the OS disk as a Premium SSD disk and leverage Ultra disks for all your workload data.

TIP

Review the latest guidance available from Microsoft when planning your deployment, as these limitations may have changed by that time.

Managed disk creation walkthrough

The following sections step you through the process of creating a managed disk using the Azure portal, Azure PowerShell, and the Azure CLI.

IMPORTANT

If you are following along, select resources and resource names based on your environment.

IMPORTANT

If you are following along, be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft.

 

Using Azure portal

To create a managed disk using the Azure portal, follow these steps:

  1. Log in to the Azure portal, type disks in the search box, and select the Disks option in the list that appears. (See Figure 3-1.)

    FIGURE 3-1

    FIGURE 3-1 Searching for the Disks service in the Azure portal.

  2. On the Disks page (see Figure 3-2), click Create.

    FIGURE 3-2

    FIGURE 3-2 Creating a new disk.

  3. In the Basics tab of the Create a Managed Disk wizard (see Figure 3-3), enter the following information:

    • Subscription Select the subscription in which you want to create the new managed disk.

    • Resource Group Select an existing resource group in which to create the new managed disk or create a new one.

    • Disk Name Enter a unique name for the managed disk.

    • Region Select the Azure region where you want to host the managed disk.

    • Availability Zone Select the availability zone you want to use or leave this option set to None (the default).

    • Source Type If the disk will be created from source data, such as a snapshot, storage blob, another disk, etc., select the source type.

    FIGURE 3-3

    FIGURE 3.3 The Basics tab of the Create a Managed Disk wizard.

  4. To create a disk that is a different redundancy level, type, size, or performance tier from the default (1,024 GiB Premium SSD LRS), click the Change Size link in the Size section of the wizard’s Basics tab.

  5. In the Select a Disk Size dialog box, open the Disk SKU drop-down list and choose a disk type/redundancy level pairing. (See Figure 3-4.)

    FIGURE 3-4

    FIGURE 3-4 Choose a disk type and redundancy level.

    NOTE

    For more on redundancy levels for managed disks, see the section “Disk redundancy” later in this chapter.

  6. Click a size option in the list to select it. Alternatively, use the Custom Disk Size (GiB) and Performance Tier drop-down lists to choose a custom size/tier pairing. Then click OK. (See Figure 3-5.)

    FIGURE 3-5

    FIGURE 3.5 Selecting a different disk size and performance tier.

  7. Back in the Basics tab of the Create a Managed Disk wizard, click Next.

  8. In the Encryption tab of the Create a Managed Disk wizard (see Figure 3-6), open the Key Management drop-down list and choose Platform-Managed Key, Customer-Managed Key, or Platform-Managed and Customer-Managed Keys. Then click Next.

    FIGURE 3-6

    FIGURE 3.6 The Encryption tab of the Create a Managed Disk wizard.

    NOTE

    To use customer-managed keys, you must first generate and store the keys in the Azure Key Vault service.

  9. In the Networking tab of the Create a Managed Disk wizard (see Figure 3-7), in the Network Access section, leave the Enable Public Access from All Networks option button selected and click Next.

    FIGURE 3-7

    FIGURE 3.7 The Networking tab of the Create a Managed Disk wizard.

  10. In the Advanced tab of the Create a Managed Disk wizard (see Figure 3-8), enter the following information and click Next:

    • Enable Shared Disk If you want to use this managed disk as a shared disk, select the Yes Option button. Then use the Max Shares drop-down list to specify how many VMs will share the disk.

    FIGURE 3-8

    FIGURE 3.8 The Advanced tab of the Create a Managed Disk wizard.

    NOTE

    For more on shared disks, see the section “Shared disks” later in this chapter.

    • On-Demand Bursting If you want this managed disk to be capable of on-demand bursting, select the Enable On-Demand Bursting check box.

    NOTE

    The Enable On-Demand Bursting check box is available only if your managed disk is 512 GB or more. This option is covered in more detail later in this chapter.

    • Enable Data Access Authentication Mode Optionally, select this check box to enable data access authentication. When you enable data access authentication, you can limit who can download the disk to admins who are authorized using Azure AD and authenticated using an approved account.

  11. In the Tags tab (see Figure 3-9), enter any tags you want to associate with the managed disk and click Next.

    FIGURE 3-9

    FIGURE 3.9 The Tags tab of the Create a Managed Disk wizard.

  12. In the Review + Create tab (see Figure 3-10), review your settings, and click Create to create the managed disk.

    FIGURE 3-10

    FIGURE 3-10 The Review + Create tab of the Create a Managed Disk wizard.

  13. After the managed disk is created, click Go to Resource to access its page. (See Figure 3-11.)

FIGURE 3-11

FIGURE 3.11 Managed disk deployment completion.

Using Azure Powershell

Use the following Azure PowerShell code to create a managed disk:

#Define variables
$resourceGroup = "RG01"
$location = "EastUS2"
$vm = "SourceVM"
$MgdDiskName = "ManagedDisk01"
 
#Create a disk config object – Change the disk redundancy as needed
$MgdDiskConfig = New-AzDiskConfig `
    -Location $location `
    -CreateOption Empty `
    -DiskSizeGB 64 `
    -EncryptionType EncryptionAtRestWithPlatformKey `
    -PublicNetworkAccess true `
    -Architecture X64 `
    -SkuName Standard_LRS/Premium_LRS/StandardSSD_LRS/UltraSSD_LRS/Premium_ZRS/
StandardSSD_ZRS
 
#Create Data Disk
$MgdDisk = New-AzDisk `
    -ResourceGroupName $resourceGroup `
    -DiskName $MgdDiskName `
    -Disk $mgddiskConfig
 
#Verify disk
Get-AzDisk `
    -ResourceGroupName $resourceGroup `
    -DiskName $MgdDiskName

#Optional - Attach disk to VM
$Azvm = Get-AzVM `
    -ResourceGroupName $resourceGroup `
    -Name $vm
 
$Azvm = Add-AzVMDataDisk `
    -VM $vm `
    -Name $MgdDiskName `
    -CreateOption Attach `
    -ManagedDiskId $MgdDisk.Id `
    -Lun 1
 
Update-AzVM `
    -ResourceGroupName $resourceGroup `
    -VM $Azvm
Using Azure CLI

Use the following code to create a managed disk in the Azure CLI:

#Define variables
resourceGroup="RG01"
location="EastUS2"
vm="SourceVM"
MgdDiskName="ManagedDisk01"
 
#Create managed disk – Change the disk redundancy as needed
az disk create                        --resource-group $resourceGroup                        --name $MgdDiskName                        --size-gb 64       --architecture x64       --encryption-type EncryptionAtRestWithPlatformKey       --location $location       --public-network-access Enabled       --sku Premium_LRS/PremiumV2_LRS/Premium_ZRS/StandardSSD_LRS/StandardSSD_ZRS/
Standard_LRS/UltraSSD_LRS
 
#Verify disk
mgddisk=$(az disk show                        --name $MgdDiskName                        --resource-group $resourceGroup)
 
#Optional - Attach disk to VM
az vm disk attach                        --disks $mgddisk       --name $MgdDiskName       --resource-group $resourceGroup                        --vm-name $vm

Private Link integration

Private Link provides secure connectivity to Azure PaaS services and Azure hosted services from your networks over a private endpoint. A private endpoint is a network interface connected to the Azure PaaS service or Azure hosted service, such as Managed Disks, that is attached to an Azure virtual network. With Private Link and private endpoints, you can safely and securely transfer managed disk files between regions using a private connection on the Microsoft backbone network instead of the public internet. You can also import VHD files from an on-premises environment directly to an empty managed disk in Azure over a private connection. Time-restricted Shared Access Signature (SAS) URLs can provide access to the unused managed disks and snapshots for transfer.

NOTE

Another book in this series, Microsoft Azure Networking: The Definitive Guide, covers Private Link in detail in Chapter 10.

Private Link integration walkthrough

The following sections step you through the process of creating a private endpoint and integrating Private Link with the managed disk using the Azure portal and the Azure CLI.

IMPORTANT

If you are following along, select resources and resource names based on your environment.

IMPORTANT

If you are following along, be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft.

Using Azure portal

To create a private endpoint and integrate Private Link with a managed disk using the Azure portal, follow these steps:

  1. Log in to the Azure portal, type disk accesses in the search box, and select the Disk Access option from the list that appears. (See Figure 3-12.)

    FIGURE 3-12

    FIGURE 3-12 Searching for disk accesses in the Azure portal.

  2. On the Disk Access page, click Create Disk Access. (See Figure 3-13.)

    FIGURE 3-13

    FIGURE 3-13 Create disk access.

  3. In the Basics tab of the Create a Disk Access wizard (see Figure 3-14), enter the following information:

    • Subscription Select the subscription in which you want to create the disk access resource.

    • Resource Group Select an existing resource group in which to create the disk access resource or create a new one.

    • Name Enter a unique name for the disk access resource.

    • Region Select the Azure region where you want to host the disk access resource.

    FIGURE 3-14

    FIGURE 3.14 The Basics tab of the Create a Disk Access wizard.

    Before you continue with the Create a Disk Access wizard, you need to create the private endpoint. You’ll do that next.

  4. At the bottom of the Basics tab, click Add.

  5. In the Create a Private Endpoint dialog box (see Figure 3-15), enter the following information and click OK:

    • Subscription Select the subscription you want to use to create the private endpoint.

    • Resource Group Select an existing resource group in which to create the private endpoint or create a new one.

    • Location Select the Azure region where you want to host the private endpoint.

    • Name Enter a unique name for the private endpoint.

    • Target Resource Select Disks.

    • Virtual Network Select the virtual network on which to create the private endpoint.

    • Subnet Select the subnet on which to create the private endpoint.

    • Integrate with Private DNS Zone Select Yes to integrate with a private DNS zone or select No if you plan to create a DNS record in your own DNS servers or on the host files of the workloads VMs. In this case, select Yes.

    • Private DNS Zone Select the private DNS zone with which you want to integrate the private endpoint. In this case, leave it set to the default, privatelink.blob.core.windows.net.

    FIGURE 3-15

    FIGURE 3.15 The Create Private Endpoint dialog box.

  6. Click the Tags tab (see Figure 3-16), enter any tags you want to associate with the private endpoint, and click Next.

    FIGURE 3-16

    FIGURE 3.16 The Tags tab of the Create a Disk Access wizard.

  7. In the Review + Create tab (see Figure 3-17), review your settings and click Create to create the private endpoint.

    FIGURE 3-17

    FIGURE 3-17 The Review + Create tab of the Create a Disk Access wizard.

  8. After the private endpoint is created, click Go to Resource to access its page. (See Figure 3-18.)

    FIGURE 3-18

    FIGURE 3.18 Private endpoint deployment completion.

  9. In the left pane of the page for the managed disk you created earlier, under Settings, click Networking.

  10. On the managed disk’s Networking page (see Figure 3-19), perform the following steps and click Save:

  • Network Access Select the Disable Public Access and Enable Private Access option button.

  • Disk Access Select the private endpoint you just created.

FIGURE 3-19

FIGURE 3.19 The managed disk’s Networking page.

Using Azure CLI

Use the following code to create a private endpoint and integrate Private Link with a managed disk in the Azure CLI:

#Define variables
resourceGroup="RG01"
location="EastUS2"
vm="SourceVM"
MgdDiskName="ManagedDisk01"
diskAccess="ManagedDisk01-DiskAccess"
vnet="VNET-01"
subnet="default"
privateEndPoint="ManagedDisk01-DiskAccess-PrivateEndpoint01"
#Create disk access
az disk-access create                        --name $diskAccess                        --resource-group $resourceGroup                        --location $location
 
diskAccessId=$(az disk-access show                        --name $diskAccess                        --resource-group $resourceGroup                        --query [id] -o tsv)
 
#Create private endpoint
az network private-endpoint create 
    --resource-group $resourceGroup     --name $privateEndPoint     --vnet-name $vnet      --subnet $subnet     --private-connection-resource-id $diskAccessId     --group-ids disks     --connection-name $privateEndPoint
 
#Create Private DNS zone config
az network private-dns zone create     --resource-group $resourceGroup     --name "privatelink.blob.core.windows.net"
 
az network private-dns link vnet create     --resource-group $resourceGroup     --zone-name "privatelink.blob.core.windows.net"     --name $privateEndPoint-DNSLink     --virtual-network $vnet     --registration-enabled false 
 
az network private-endpoint dns-zone-group create    --resource-group $resourceGroup    --endpoint-name $privateEndPoint    --name $privateEndPoint-ZoneGroup    --private-dns-zone "privatelink.blob.core.windows.net"    --zone-name disks
 
#Update managed disk with Private Link config
diskAccessId=$(az resource show    --name $diskAccess    --resource-group $resourceGroup    --namespace Microsoft.Compute    --resource-type diskAccesses    --query [id] -o tsv)
 
az disk update    --name $diskName    --resource-group $resourceGroup    --network-access-policy AllowPrivate    --disk-access $diskAccessId

Encryption

Managed disks support two types of disk encryption:

  • Server-Side Encryption (SSE) SSE manages encryption on the storage layer and is handled by the Azure Storage service. It provides encryption-at-rest and during write operations to the underlying storage, thereby ensuring that disks stored in Azure are not readable in the event of data theft. SSE is enabled by default for all managed disks, snapshots, and images across all Azure regions. SSE supports two types of key management: Azure platform-managed keys or customer-managed keys. You can choose which type of key management you want to use for each managed disk you create.

  • Azure Disk Encryption (ADE) ADE refers to encryption within the system. It applies to the OS and data disks in an Azure IaaS VM. ADE encryption is performed using BitLocker technology in Windows and DM-Crypt technology in Linux. In both scenarios, the keys are integrated and stored in Azure Key Vault to make it easier for you to manage them.

Managed disk snapshots

Snapshots provide an easy way to back up a point-in-time copy of your managed disk for restore or cloning operations. Snapshots are read-only, crash-consistent copies of the disk. You can use them to create new managed disks without affecting the source managed disk in any way. Snapshots are, by default, stored as standard managed disks, but you can change this during the snapshot creation process.

IMPORTANT

While snapshots serve as a great way to create a copy of a managed disk, they are not a replacement for regular backups, and you should not use them as such.

The first time you take a snapshot of a managed disk, it will be a full snapshot. Subsequent snapshots, however, can be incremental. An incremental snapshot captures all changes to the managed disk since the last snapshot of the disk. This reduces your storage footprint. If you need to restore from a single incremental snapshot, Azure automatically identifies all the incremental and full snapshots preceding the current one to reconstruct the entire disk. This makes incremental snapshots extremely cost-effective, making them the preferred option for regular snapshot management.

NOTE

If the zone in which the incremental snapshot is created provides ZRS redundancy capabilities, then the incremental snapshot will automatically be saved with ZRS, too, unless specified otherwise.

NOTE

If you are using full snapshots on premium storage to scale up VM deployments, we recommend you use custom images on standard storage in the Shared Image Gallery. This will help you achieve a more massive scale with a lower cost. For more on this, see Chapter 2, “Virtual Machine Scale Sets,” in Microsoft Azure Compute: The Definitive Guide.

Incremental snapshots can also be useful for disaster recovery between Azure regions—that is, you can identify changes between two snapshots of the same disk, and then transfer only the differential changes to the secondary region instead of the entire snapshot. Then, when you restore/rebuild in the secondary region, you can use the snapshot of the base blob of the managed disk in combination with these differential changes. (See Figure 3-20.) This strategy can reduce time, costs, and network requirements for disaster recovery for managed disks.

FIGURE 3-20

FIGURE 3.20 Incremental snapshots.

NOTE

Microsoft provides sample .NET code online to help you test this capability if you are interested in exploring it.

Incremental snapshots are a great feature, but they do have some limitations that exist at the time of this writing. By the time you read this, these limitations may have been addressed. Be sure to review Microsoft’s latest guidance before finalizing your snapshot management strategy. Some key limitations at present include the following:

  • Unlike full snapshots, incremental snapshots always use Standard HDD disks, regardless of the disk type used for the full snapshot.

  • A single managed disk supports a maximum of 500 incremental snapshots.

  • Each managed disk limits you to creating seven incremental snapshots, with a wait time of 5 minutes between each snapshot.

  • The managed disk and snapshots must all be part of the same subscription.

  • If you want to move a managed disk to another subscription, you will not be able to do so if the disk has incremental snapshots. You will need to keep this in mind when planning any such migrations.

  • Differentials do not work for disks larger than 4 TB.

Managed disk snapshots walkthrough

The following sections step you through the process of creating a snapshot of a managed disk using the Azure portal, Azure PowerShell, and the Azure CLI.

IMPORTANT

If you are following along, select resources and resource names based on your environment.

IMPORTANT

If you are following along, be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft.

Using Azure portal

To create a managed disk snapshot using the Azure portal, follow these steps:

  1. In the Overview page for the managed disk you created earlier, click Create Snapshot. (See Figure 3-21.)

    FIGURE 3-21

    FIGURE 3.21 The Overview page for ManagedDisk01.

  2. In the Basics tab of the Create Snapshot wizard (see Figure 3-22), enter the following information and click Next:

    • Subscription Select the subscription in which you want to create the snapshot.

    • Resource Group Select an existing resource group in which to create the snapshot or create a new one.

    • Name Enter a unique name for the snapshot.

    • Snapshot Type Leave this set to the default value of Full.

      FIGURE 3-22

      FIGURE 3.22 The Basics tab of the Create Snapshot wizard.

      NOTE

      Figure 3-22 shows a Full button and an Incremental button. Your screen might not reflect that because this is the first time you’re creating a snapshot of this managed disk. The next time you create a snapshot, you’ll want to choose the Incremental button.

    • Storage Type Select Standard HDD, Standard SSD, or Premium SSD, depending on your needs. (Remember, this is for the full snapshot; incremental snapshots always use Standard HDD disks.)

  3. In the Encryption tab of the Create Snapshot wizard (see Figure 3-23), open the Key Management drop-down list and choose Platform-Managed Key, Customer-Managed Key, or Platform-Managed and Customer-Managed Keys. Then click Next.

    FIGURE 3-23

    FIGURE 3.23 The Encryption tab of the Create Snapshot wizard.

    NOTE

    To use customer-managed keys, you must first generate and store the keys in the Azure Key Vault service.

  4. In the Networking tab of the Create Snapshot wizard (see Figure 3-24), in the Network Access section, select the Enable Public Access from All Networks option button.

    FIGURE 3-24

    FIGURE 3.24 The Networking tab of the Create Snapshot wizard.

  5. The Advanced tab of the Create Snapshot wizard (see Figure 3-25) includes an Enable Data Access Authentication Mode check box. For this example, leave it unchecked. Then click Next.

    FIGURE 3-25

    FIGURE 3.25 The Advanced tab of the Create Snapshot wizard.

  6. In the Tags tab (see Figure 3-26), enter any tags you want to associate with the snapshot and click Next.

    FIGURE 3-26

    FIGURE 3.26 The Tags tab of the Create Snapshot wizard.

  7. In the Review + Create tab (see Figure 3-27), review your settings, and click Create to create the snapshot.

    FIGURE 3-27

    FIGURE 3-27 The Review + Create tab of the Create Snapshot wizard.

  8. After the snapshot is created, click Go to Resource to access its page. (See Figure 3-28.)

    FIGURE 3-28

    FIGURE 3.28 Snapshot deployment completion.

    The snapshot’s Overview page displays the properties of the snapshot, as well as Create Disk, Copy Snapshot, Delete, and Refresh options. (See Figure 3-29.)

    FIGURE 3-29

    FIGURE 3.29 The new disk snapshot’s Overview page.

Using Azure Powershell

Use the following Azure PowerShell code to create a disk snapshot:

#Define variables
$resourceGroup = "RG01"
$location = "EastUS2"
$vm = "SourceVM"
$snapshotName = "SourceVM-Snapshot-20230228"
 
#get the VM
$vminfo = Get-AzVM `
    -ResourceGroupName $resourceGroup `
    -Name $vm
 
#Create the snapshot configuration
$snapshotconfig =  New-AzSnapshotConfig `
    -SourceUri $vminfo.StorageProfile.OsDisk.ManagedDisk.Id `
    -Location $location `
    -CreateOption copy
 
#Take the snapshot.
New-AzSnapshot `
    -Snapshot $snapshotconfig `
    -SnapshotName $snapshotName `
    -ResourceGroupName $resourceGroup
 
#Verify snapshot
Get-AzSnapshot `
    -ResourceGroupName $resourceGroup
Using Azure CLI

Use the following code to create a disk snapshot in the Azure CLI:

#Define variables
resourceGroup="RG01"
location="EastUS2"
vm="SourceVM"
snapshotName="SourceVM-Snapshot-20230228"
 
#get the VM
DiskInfo=$(az vm show    --resource-group $resourceGroup    --name $vm    --query "storageProfile.osDisk.managedDisk.id"    -o tsv)
 
#Take the snapshot.
az snapshot create    --resource-group $resourceGroup                        --source "$DiskInfo"                        --name $snapshotName
 
#Verify snapshot
az snapshot list    --resource-group $resourceGroup    -o table

Managed images

Managed images enable you to create hundreds of copies of customized VMs in Azure without having to create multiple copies of the underlying disks associated with each VM or manage any storage accounts to host them. You can easily create managed images out of managed disks; the resulting managed image will contain the configuration of the source VM, including all the managed disks associated with that source VM. This helps you to scale your VM resources using features like VMSS or Azure Virtual Desktop Session Host Pools, where capacity is added as load increases.

The primary difference between managed disks and managed images is that an image is built from a generalized VM and includes all the associated disks, whereas a snapshot is specific to a single disk and is a point-in-time copy of that disk. Generalizing a VM removes machine and user-specific information from the VM. So, for a VM that has multiple disks using disk spanning, a snapshot currently does not support a coordinated restore of all the disks and, therefore, might not be the right solution.

Managed images walkthrough

The following sections step you through the process of creating a managed image using the Azure portal, Azure PowerShell, and the Azure CLI.

IMPORTANT

If you are following along, select resources and resource names based on your environment.

IMPORTANT

If you are following along, be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft.

PREREQUISITE

If you are following along, you must create a VM to use to create the managed image. Be sure to stop that VM before starting the following procedure, however. The wizard will generalize this VM and make it unusable after the image is captured. (Optionally, you back up the VM and restore it after the process is complete.)

Using Azure portal

To create a managed image using the Azure portal, follow these steps:

  1. On the Overview page of the VM for which you want to create an image, click Capture. (See Figure 3-30.)

    FIGURE 3-30

    FIGURE 3.30 The Overview page for the VM.

  2. In the Basics tab of the Create an Image wizard (see Figure 3-31), enter the following information and click Next:

    • Resource Group Select an existing resource group in which to create the new managed image or create a new one.

    • Share Image to Azure Compute Gallery For this walkthrough, select the No, Capture Only a Managed Image option button.

    • Automatically Delete this Virtual Machine After Creating the Image Leave this checkbox unchecked (the default).

    • Zone Resiliency Select this check box if you want to create a zone redundant image.

    • Name Enter a unique name for the managed image.

    FIGURE 3-31

    FIGURE 3.31 The Basics tab of the Create an Image wizard.

  3. In the Tags tab (see Figure 3-32), enter any tags you want to associate with the managed image and click Next.

    FIGURE 3-32

    FIGURE 3.32 The Tags tab of the Create an Image wizard.

  4. In the Review + Create tab (see Figure 3-33), review your settings, and click Create to create the managed image.

    FIGURE 3-33

    FIGURE 3-33 The Review + Create tab of the Create an Image wizard.

    The source VM will be stopped automatically if you haven’t turned it off already. (See Figure 3-34.) Azure will then generalize the VM and create the image.

    FIGURE 3-34

    FIGURE 3-34 The VM is stopped (unless you stopped it already).

  5. After the managed image is created, click Go to Resource to access its page. (See Figure 3-35.)

    FIGURE 3-35

    FIGURE 3.35 Managed image deployment completion.

    The managed image’s Overview page displays the properties of the managed image as well as Create VM, Clone to a VM Image, Delete, and Refresh options. (See Figure 3-36.)

FIGURE 3-36

FIGURE 3.36 The new managed image’s Overview page.

Using Azure Powershell

Use the following Azure PowerShell code to create a managed image:

#Define variables
$vm = "SourceVM"
$resourcegroup = RG01
$location = "EastUS2"
$imageName = "SourceVM-Image-20221203"
 
#VM has been deallocated
Stop-AzVM -ResourceGroupName $resourcegroup -Name $vm -Force
 
#Set the status of the virtual machine to Generalized.
Set-AzVm -ResourceGroupName $resourcegroup -Name $vm -Generalized
 
#Create the image configuration.
$vminfo = Get-AzVM -Name $vm -ResourceGroupName $resourcegroup
$vmimage = New-AzImageConfig -Location $location -SourceVirtualMachineId $vminfo.Id
 
#Create the image.
New-AzImage -Image $vmimage -ImageName $imageName -ResourceGroupName $resourcegroup
Using Azure CLI

Use the following code to create a managed image in the Azure CLI:

#Define variables
vm="SourceVM"
resourcegroup=$RG01
location="EastUS2"
imageName="SourceVM-Image-20221203"
 
#VM has been deallocated
az vm deallocate     --resource-group $resourcegroup     --name $vm
 
#Set the status of the virtual machine to Generalized.
az vm generalize     --resource-group $resourcegroup     --name $vm
 
#Create the image.
az image create     --resource-group $resourcegroup --location $location --zone-resilient false  --name $imageName --source $vm
Save to your account

This chapter is from the book