Azure Site Recovery 2026: NVMe VMs, Shared Disks, and Performance Plus Replication

Every DR assessment I run starts the same way: map the production estate, then check what Azure Site Recovery (ASR) can actually protect. For years, that second step produced an uncomfortable list of exceptions. Modern VMs with NVMe disk controllers? Not supported. Windows Server Failover Clusters on shared disks? Not supported. Disks with Performance Plus enabled? Partial support with caveats.

Those gaps have now closed. The current ASR support matrix lists NVMe storage interfaces as supported for Azure-to-Azure replication, shared disks as supported via Windows Server Failover Clustering (WSFC), and Performance Plus disks as supported. If your DR strategy was constrained by any of these, it is worth re-evaluating.

This article covers what is supported today, what is still excluded, and how to configure each of the three — with the exact PowerShell and CLI commands.

Why These Gaps Mattered

These were not edge cases. Each gap blocked a common production pattern:

• NVMe VMs are the modern default. The v6-series general-purpose and memory-optimized families (Da/Ea/Fa v6), plus storage-optimized Ebsv5/Ebdsv5 SKUs, use NVMe disk interfaces. As fleets upgraded from older generations, an increasing share of VMs quietly fell out of ASR scope.
• Clustered workloads need shared storage. SQL Server Failover Cluster Instances (FCI), SAP ASCS/SCS, and scale-out file servers all depend on shared disks. Without shared-disk replication, DR for these meant maintaining a parallel cluster in the recovery region by hand.
• Performance Plus is increasingly common. Enabling Performance Plus on a disk raises its IOPS and throughput limits without paying for a larger tier — attractive for database disks. But if the performance configuration did not survive replication, your failover environment ran slower than production.

The result was DR coverage that looked complete on a slide but had holes exactly where the most important workloads lived.

What Is Supported Now

1. NVMe Disk Controller Support

Per the current Azure-to-Azure support matrix, NVMe is supported for Azure-to-Azure replication:

• Windows: supported on Gen2 VMs that use the NVMe interface — Da/Ea/Fa v6-series, Ddsv6, Edsv6, Ebsv5/Ebdsv5, and others.
• Linux: supported for RHEL 9, SLES 15, and Ubuntu 24 on the same Gen2 NVMe families — currently in preview.

What is still excluded:

• Ephemeral OS disks and local NVMe disks are not replicated (they are local-only storage by design).
• Mixed-controller VMs (SCSI + NVMe) are not supported — this includes VM SKUs such as Lsv3.

Practically: if your fleet standardizes on v6-series compute with managed NVMe data disks, you can now enable ASR without per-VM exceptions. Linux NVMe support being in preview means it is usable for evaluation and non-critical workloads, but check the preview status before relying on it for production RPO commitments.

Enabling replication for an NVMe VM follows the standard Azure-to-Azure flow — nothing NVMe-specific to configure. The CLI extension command looks like this (fabric, container, and mapping created first):

az site-recovery protected-item create -g rg-dr --fabric-name fabric-source \
  -n rpi-vm-nvme --protection-container container-source \
  --vault-name asr-vault --policy-id $POLICY_ID \
  --provider-details '{a2a:{fabric-object-id:'$VM_ID',vm-managed-disks:[{disk-id:'$OS_DISK_ID',primary-staging-azure-storage-account-id:'$CACHE_SA_ID',recovery-resource-group-id:'$TARGET_RG_ID}],recovery-azure-network-id:'$RECOVERY_VNET_ID',recovery-container-id:'$RECOVERY_CONTAINER_ID',recovery-resource-group-id:'$TARGET_RG_ID',recovery-subnet-name:default}}'

Note the command name is az site-recovery protected-item create (the site-recovery CLI extension), not az site-recovery replication-protected-item create — that older name does not exist and appears in a lot of AI-generated guides.

2. Shared Disks via Windows Server Failover Clustering

ASR can now replicate Azure shared disks, with one hard constraint: the sharing must be orchestrated by WSFC on Windows Server 2016 or later, in an active-passive configuration. Linux shared-disk configurations are not supported.

The support matrix for shared disks:

Explicitly unsupported:

• Active-Active clusters
• Protecting multiple clusters as a single group
• Mixing clustered and non-clustered VMs in one protection group
• Non-clustered distributed appliances that don't use WSFC
• VMs in a cluster attached to different shared disk sets — every protected VM must share the same set of disks

The key operational behavior: ASR treats the cluster as a single unit. Recovery points are cluster-consistent across all VMs and all disks (including the shared disk), failover is one action, and reprotect/failback is one action. You don't orchestrate per-node recovery yourself.

Two more constraints to plan around:

• All-or-nothing enablement: you can only enable replication successfully when all VMs attached to a shared disk are selected. You can exclude the shared disk itself (with a warning), but you cannot protect some nodes and not others.
• No domain controllers: ASR shared-disk support does not cover Active Directory VMs — keep your DCs out of the protection group.
• Crash-consistent recovery points only: ASR for shared disks supports crash-consistent recovery points — app-consistent snapshots are not available for shared-disk clusters, so plan the SQL/SAP recovery flow around crash-consistent points (SQL FCI recovers cleanly from them via database recovery at startup).

3. Performance Plus Disk Support

Performance Plus raises the IOPS and throughput limits of a managed disk to the expanded maximums for its size — with no extra charge for the capability itself. ASR's support matrix confirms Performance Plus disks are supported for replication (Standard HDD, Standard SSD, and Premium SSD disks, using premium storage accounts during replication).

Two facts about Performance Plus that shape your DR design:

1. Eligibility: Standard HDD, Standard SSD, or Premium SSD managed disks, 513 GiB or larger.
2. Creation-only: Performance Plus can only be enabled when the disk is created. You cannot flip it on an existing disk. The migration path is snapshot → create new disk from snapshot with the flag.

# Create a 513 GiB Premium SSD with Performance Plus enabled
az disk create \
  -g rg-prod -n data-disk-perfplus \
  --size-gb 513 --sku Premium_LRS \
  --performance-plus true

# Migrate an existing disk: snapshot, then recreate with the flag
az snapshot create -g rg-prod -n snap-data-disk --source data-disk-existing
az disk create -g rg-prod -n data-disk-migrated \
  --size-gb 513 --sku Premium_LRS \
  --source snap-data-disk --performance-plus true

The DR implication: Performance Plus is a property of the source disk at creation time, and ASR replicates the disk data to replica disks in the target region. If performance characteristics matter at failover (and for database workloads they always do), validate in a test failover that the recovered disks deliver the IOPS/throughput you expect — and remember that for Premium SSD v2, the IOPS copied is the value at the time replication was enabled, not live values.

Practical Setup: SQL FCI on Shared Disks

The most common shared-disk scenario is SQL Server FCI. Here is the PowerShell flow using Az.RecoveryServices — note that shared-disk replication is a PowerShell/portal feature; the CLI extension does not expose the protection-cluster concept.

After creating the vault, fabrics, containers, and network mappings (the standard A2A setup), you create a protection cluster — the ASR container that groups all replicated items belonging to one WSFC cluster:

# Create the protection cluster for the WSFC
$clusterJob = New-AzRecoveryServicesAsrReplicationProtectionCluster -AzureToAzure `
  -Name "sql-fci-cluster" -ProtectionContainerMapping $forwardpcm

$cluster = Get-AzRecoveryServicesAsrReplicationProtectionCluster `
  -ProtectionContainer $pc -Name "sql-fci-cluster"

Then enable replication for each node, passing the cluster and per-disk replication config (normal disks and the shared disk in the same configuration):

# Disk replication config: include every disk, including the shared one
$disk1 = New-AzRecoveryServicesAsrAzureToAzureDiskReplicationConfig -ManagedDisk `
  -LogStorageAccountId $cacheSaId -DiskId $osDiskId `
  -RecoveryResourceGroupId $targetRgId `
  -RecoveryReplicaDiskAccountType Premium_LRS `
  -RecoveryTargetDiskAccountType Premium_LRS

$disk2 = New-AzRecoveryServicesAsrAzureToAzureDiskReplicationConfig -ManagedDisk `
  -LogStorageAccountId $cacheSaId -DiskId $sharedDiskId `
  -RecoveryResourceGroupId $targetRgId `
  -RecoveryReplicaDiskAccountType Premium_LRS `
  -RecoveryTargetDiskAccountType Premium_LRS

$disks = @($disk1, $disk2)

# Enable protection for this cluster node
$enableJob = New-AzRecoveryServicesAsrReplicationProtectedItem -AzureToAzure `
  -Name $rpiName -AzureToAzureDiskReplicationConfiguration $disks `
  -ReplicationProtectionCluster $cluster -AzureVmId $vmId `
  -ProtectionContainerMapping $forwardpcm -RecoveryResourceGroupId $targetRgId `
  -RecoveryAvailabilitySetId $avsetId -RecoveryProximityPlacementGroupId $ppgId `
  -RecoveryAzureNetworkId $networkId -LogStorageAccountId $cacheSaId

Repeat for the second node. The disk replication configuration must contain both the normal disks and the shared disk information, and every VM in the cluster must be included.

Then: run a test failover. For clustered workloads this is not optional — you need to confirm the cluster quorum comes up in the recovery region, the shared disk attaches to the surviving node, and SQL/SAP actually starts. Budget a maintenance window and do it before your first DR audit, not during one.

Planning Numbers That Hold Up

Rather than invent RPO/RTO figures, anchor on what ASR actually guarantees and configure:

Your actual RTO depends on churn rate, disk sizes, and how fast the target VMs boot — the only honest way to publish an RTO number is to measure it with test failovers and re-measure as the workload grows.

Cost model: ASR is billed per protected instance (each VM counts as one instance), with the first 31 days of protection free per instance. On top of the service fee you pay for replica storage in the target region, storage transactions, and egress. There is no documented separate per-shared-disk ASR fee — the shared disk is replicated like any other disk, so it adds replica storage cost rather than a licensing line. Performance Plus itself carries no extra charge. Check the current pricing page for your regions before quoting numbers to a customer.

Pitfalls to Plan Around

1. Performance Plus cannot be retrofitted. It is creation-only. If your production disks don't have it and your DR disks need to match, you'll be doing snapshot-migrate-dance on production disks. Plan that migration deliberately rather than discovering it mid-failover-test.
2. Mixed SCSI+NVMe VMs are out of scope. If a VM has both controller types (e.g., Lsv3-style SKUs), it cannot be replicated. Split the workload or change SKU before committing to an ASR-based DR design.
3. Linux NVMe support is preview. Fine for validation and lower-tier workloads; confirm GA status before writing production RPO commitments against it.
4. Shared disks are Windows/WSFC/active-passive only. Linux Pacemaker clusters, active-active configurations, and non-WSFC distributed appliances are not covered — those need a different DR pattern (application-level replication, geo-replicated storage, or a warm standby).
5. All-or-nothing cluster protection. Selecting half the cluster fails or produces warnings. Decide the cluster boundary up front and protect the whole thing.
6. Don't trust AI-generated ASR CLI examples. The Azure CLI site-recovery extension command names differ from what most generated guides show (there is no az site-recovery replication-protected-item create), and shared-disk flows are PowerShell/portal only. Validate commands against the current docs before running them.
7. Premium SSD v2 IOPS is frozen at enablement. If source v2 disk IOPS changes after replication is enabled, the failover disk gets the old value. Adjust after failover if needed.

Key Takeaways

1. NVMe VMs are now protectable by ASR — Windows is supported and Linux (RHEL 9, SLES 15, Ubuntu 24 on Gen2 NVMe families) is in preview. Ephemeral/local NVMe and mixed-controller VMs remain excluded.
2. Shared-disk DR means WSFC clusters survive region loss — SQL FCI, SAP ASCS/SCS, and file server clusters can be protected, failed over, and failed back as a single unit with cluster-consistent recovery points. Windows, active-passive, all nodes together.
3. Performance Plus is supported and free, but creation-only and 513 GiB+ — design your disk provisioning around it rather than trying to retrofit it later.
4. Test failover is mandatory for clustered workloads — quorum behavior and shared-disk attachment in the recovery region are exactly where silent DR failures hide.
5. Anchor RPO/RTO on measured test failovers, not vendor-agnostic estimates: ASR gives you 5-minute crash-consistent frequency and configurable app-consistent snapshots; your RTO is what you measure.

If your DR estate includes any of these workload types, this is a good quarter to close the coverage gap — the features are in the support matrix now, and the configuration is documented. The only thing left is the test failover.