diff --git a/articles/virtual-machines/includes/disks-premv2-regions.md b/articles/virtual-machines/includes/disks-premv2-regions.md index b12c25cc5df..2fa0a46f122 100644 --- a/articles/virtual-machines/includes/disks-premv2-regions.md +++ b/articles/virtual-machines/includes/disks-premv2-regions.md @@ -42,4 +42,4 @@ Currently only available in the following regions: - West US 2 (Three availability zones) - West US 3 (Three availability zones) -To learn when support for particular regions was added, see either [Azure Updates](https://azure.microsoft.com/updates/?query=disk%20storage) or [What's new for Azure Disk Storage](../disks-whats-new.md). +To learn when support for particular regions was added, see either [Azure Updates](https://azure.microsoft.com/updates/?query=disk%20storage) or [What's new for Azure Disk Storage](/azure/virtual-machines/disks-whats-new). diff --git a/articles/virtual-machines/includes/managed-disks-bursting-2.md b/articles/virtual-machines/includes/managed-disks-bursting-2.md index 1d4194390cd..feaec90f7e0 100644 --- a/articles/virtual-machines/includes/managed-disks-bursting-2.md +++ b/articles/virtual-machines/includes/managed-disks-bursting-2.md @@ -10,9 +10,9 @@ --- ### On-demand bursting -Premium SSD managed disks using the on-demand bursting model of disk bursting can burst beyond original provisioned targets, as often as needed by their workload, up to the max burst target. For example, on a 1-TiB P30 disk, the provisioned IOPS is 5000 IOPS. When disk bursting is enabled on this disk, your workloads can issue IOs to this disk up to the max burst performance of 30,000 IOPS and 1,000 MBps. For the max burst targets on each supported disk, see [Scalability and performance targets for VM disks](../disks-scalability-targets.md#premium-ssd-managed-disks-per-disk-limits). +Premium SSD managed disks using the on-demand bursting model of disk bursting can burst beyond original provisioned targets, as often as needed by their workload, up to the max burst target. For example, on a 1-TiB P30 disk, the provisioned IOPS is 5000 IOPS. When disk bursting is enabled on this disk, your workloads can issue IOs to this disk up to the max burst performance of 30,000 IOPS and 1,000 MBps. For the max burst targets on each supported disk, see [Scalability and performance targets for VM disks](/azure/virtual-machines/disks-scalability-targets#premium-ssd-managed-disks-per-disk-limits). -If you expect your workloads to frequently run beyond the provisioned perf target, disk bursting won't be cost-effective. In this case, we recommend that you change your disk's performance tier to a [higher tier](../disks-performance-tiers.md) instead, for better baseline performance. Review your billing details and assess that against the traffic pattern of your workloads. +If you expect your workloads to frequently run beyond the provisioned perf target, disk bursting won't be cost-effective. In this case, we recommend that you change your disk's performance tier to a [higher tier](/azure/virtual-machines/disks-performance-tiers) instead, for better baseline performance. Review your billing details and assess that against the traffic pattern of your workloads. Before you enable on-demand bursting, understand the following: @@ -35,11 +35,11 @@ Disk configuration: Premium SSD – 1 TiB (P30), Disk bursting enabled. In this billing hour, the cost of bursting consists of two charges: -The first charge is the burst enablement flat fee of $X (determined by your region). This flat fee is always charged on the disk disregard of the attach status until it is disabled. +The first charge is the burst enablement flat fee of $X (determined by your region). This flat fee is always charged on the disk disregard of the attach status until it's disabled. -Second is the burst transaction cost. Disk bursting occurred in two time slots. From 00:10:01 – 00:10:10, the accumulated burst transaction is (6,000 – 5,000) X 10 = 10,000. From 00:59:01 – 01:00:00, the accumulated burst transaction is (7,000 – 5,000) X 60 = 120,000. The total burst transactions are 10,000 + 120,000 = 130,000. Burst transaction cost will be charged at $Y based on 13 units of 10,000 transactions (based on regional pricing). +Second is the burst transaction cost. Disk bursting occurred in two time slots. From 00:10:01 – 00:10:10, the accumulated burst transaction is (6,000 – 5,000) X 10 = 10,000. From 00:59:01 – 01:00:00, the accumulated burst transaction is (7,000 – 5,000) X 60 = 120,000. The total burst transactions are 10,000 + 120,000 = 130,000. Burst transaction cost is charged at $Y based on 13 units of 10,000 transactions (based on regional pricing). -With that, the total cost on disk bursting of this billing hour equals to $X + $Y. The same calculation would apply for bursting over provisioned target of MBps. We translate the overage of MB to transactions with IO size of 256KB. If your disk traffic exceed both provisioned IOPS and MBps target, you can refer to the example below to calculate the burst transactions. +With that, the total cost on disk bursting of this billing hour equals to $X + $Y. The same calculation would apply for bursting over provisioned target of MBps. We translate the overage of MB to transactions with IO size of 256 KB. If your disk traffic exceed both provisioned IOPS and MBps target, you can refer to the example below to calculate the burst transactions. Disk configuration: Premium SSD – 1 TB (P30), Disk bursting enabled. @@ -51,7 +51,7 @@ The burst transaction is accounted as the max number of transactions from either You can refer to the [Managed Disks pricing page](https://azure.microsoft.com/pricing/details/managed-disks/) for details on pricing and use [Azure Pricing Calculator](https://azure.microsoft.com/pricing/calculator/?service=storage) to make the assessment for your workload. -To enable on-demand bursting, see [Enable on-demand bursting](../disks-enable-bursting.md). +To enable on-demand bursting, see [Enable on-demand bursting](/azure/virtual-machines/disks-enable-bursting). ### Credit-based bursting @@ -60,7 +60,7 @@ For Premium SSD managed disks, credit-based bursting is available for disk sizes ## Virtual machine-level bursting -VM-level bursting only uses the credit-based model for bursting, it is enabled by default for most Premium Storage supported VMs. +VM-level bursting only uses the credit-based model for bursting, it's enabled by default for most Premium Storage supported VMs. ## Bursting flow @@ -69,7 +69,7 @@ The bursting credit system applies in the same manner at both the VM level and d ![Bursting bucket diagram.](media/managed-disks-bursting/bucket-diagram.jpg) -How you spend your available credits is up to you. You can use your 30 minutes of burst credits consecutively or sporadically throughout the day. When resources are deployed they come with a full allocation of credits. When those deplete, it takes less than a day to restock. Credits can be spent at your discretion, the burst bucket does not need to be full in order for resources to burst. Burst accumulation varies depending on each resource, since it is based on unused IOPS and MB/s below their performance targets. Higher baseline performance resources can accrue their bursting credits faster than lower baseline performing resources. For example, a P1 disk idling will accrue 120 IOPS per second, whereas an idling P20 disk would accrue 2,300 IOPS per second. +How you spend your available credits is up to you. You can use your 30 minutes of burst credits consecutively or sporadically throughout the day. When resources are deployed, they come with a full allocation of credits. When those deplete, it takes less than a day to restock. Credits can be spent at your discretion. The burst bucket doesn't need to be full in order for resources to burst. Burst accumulation varies depending on each resource, since it's based on unused IOPS and MB/s below their performance targets. Higher baseline performance resources can accrue their bursting credits faster than lower baseline performing resources. For example, a P1 disk idling accrues 120 IOPS per second, whereas an idling P20 disk would accrue 2,300 IOPS per second. ## Bursting states There are three states your resource can be in with bursting enabled: @@ -79,9 +79,9 @@ There are three states your resource can be in with bursting enabled: ## Bursting examples -The following examples show how bursting works with various VM and disk combinations. To make the examples easy to follow, we will focus on MB/s, but the same logic is applied independently to IOPS. +The following examples show how bursting works with various VM and disk combinations. To make the examples easy to follow, we focus on MB/s, but the same logic is applied independently to IOPS. -### Burstable virtual machine with non-burstable disks +### Burstable virtual machine with nonburstable disks **VM and disk combination:** - Standard_L8s_v2 - Uncached MB/s: 160 @@ -93,7 +93,7 @@ The following examples show how bursting works with various VM and disk combinat - Provisioned MB/s: 250 - On-Demand Bursting: **not enabled** - After the initial boot up, an application is run on the VM and has a non-critical workload. This workload requires 30 MB/s that gets spread evenly across all the disks. + After the initial boot up, an application is run on the VM and has a noncritical workload. This workload requires 30 MB/s that gets spread evenly across all the disks. ![Application sends request for 30 MB/s of throughput to VM, VM takes request and sends each of its disks a request for 10 MB/s, each disk returns 10 MB/s, VM returns 30 MB/s to application.](media/managed-disks-bursting/bursting-vm-nonbursting-disk/burst-vm-nonbursting-disk-normal.jpg) Then the application needs to process a batched job that requires 600 MB/s. The Standard_L8s_v2 bursts to meet this demand and then requests to the disks get evenly spread out to P50 disks. @@ -112,11 +112,11 @@ Then the application needs to process a batched job that requires 600 MB/s. The - Provisioned MB/s: 25 - Max burst MB/s: 170 -When the VM starts, it will burst to request its burst limit of 1,280 MB/s from the OS disk and the OS disk will respond with its burst performance of 170 MB/s. +When the VM starts, it will burst to request its burst limit of 1,280 MB/s from the OS disk, and the OS disk will respond with its burst performance of 170 MB/s. ![At startup, the VM bursts to send a request of 1,280 MB/s to the OS disk, OS disk bursts to return the 1,280 MB/s.](media/managed-disks-bursting/bursting-vm-bursting-disk/burst-vm-burst-disk-startup.jpg) -After startup, you start an application that has a non-critical workload. This application requires 15 MB/s that gets spread evenly across all the disks. +After startup, you start an application that has a noncritical workload. This application requires 15 MB/s that gets spread evenly across all the disks. ![Application sends request for 15 MB/s of throughput to VM, VM takes request and sends each of its disks a request for 5 MB/s, each disk returns 5 MB/s responses, VM returns 15 MB/s to application.](media/managed-disks-bursting/bursting-vm-bursting-disk/burst-vm-burst-disk-idling.jpg) diff --git a/articles/virtual-machines/includes/managed-disks-ultra-disks-ga-scope-and-limitations.md b/articles/virtual-machines/includes/managed-disks-ultra-disks-ga-scope-and-limitations.md index c4ac0cad738..f74b66d7d33 100644 --- a/articles/virtual-machines/includes/managed-disks-ultra-disks-ga-scope-and-limitations.md +++ b/articles/virtual-machines/includes/managed-disks-ultra-disks-ga-scope-and-limitations.md @@ -15,12 +15,12 @@ The following list contains Ultra Disk's limitations: - Currently, Ultra Disks only support Single VM and Availability zone infrastructure options. - Ultra Disks don't support availability sets. - The size of an Ultra Disk can't be expanded without either deallocating the VM or detaching the Ultra Disk. -- Existing disks currently can't change their type to an Ultra Disk. They must be [migrated](../disks-convert-types.md#migrate-to-premium-ssd-v2-or-ultra-disk-using-snapshots). -- Currently, Azure Government and Azure China don't support [customer-managed keys](../disk-encryption.md#customer-managed-keys) for Ultra disks. +- Existing disks currently can't change their type to an Ultra Disk. They must be [migrated](/azure/virtual-machines/disks-convert-types?tabs=azure-powershell#migrate-to-premium-ssd-v2-or-ultra-disk-using-snapshots). +- Currently, Azure Government and Azure China don't support [customer-managed keys](/azure/virtual-machines/disk-encryption#customer-managed-keys) for Ultra disks. - Azure Disk Encryption isn't supported for VMs with Ultra Disks. Instead, you should use encryption at rest with platform-managed or customer-managed keys. - Azure Site Recovery isn't supported for VMs with Ultra Disks. - Ultra Disks don't support disk caching. -- Snapshots are supported with [other limitations](../disks-incremental-snapshots.md#incremental-snapshots-of-premium-ssd-v2-and-ultra-disks). +- Snapshots are supported with [other limitations](/azure/virtual-machines/disks-incremental-snapshots?tabs=azure-powershell#incremental-snapshots-of-premium-ssd-v2-and-ultra-disks). - Azure Backup support for VMs with Ultra Disks is [generally available](/azure/backup/backup-support-matrix-iaas#vm-storage-support). Azure Backup has limitations when using Ultra Disks, see [VM storage support](/azure/backup/backup-support-matrix-iaas#vm-storage-support) for details. Ultra Disks support a 4k physical sector size by default but also supports a 512E sector size. Most applications are compatible with 4k sector sizes, but some require 512-byte sector sizes. Oracle Database, for example, requires release 12.2 or later in order to support 4k native disks. For older versions of Oracle DB, 512-byte sector size is required. @@ -41,9 +41,9 @@ Not every VM size is available in every supported region with Ultra Disks. The f |VM Type |Sizes |Description | |------------|---------|-------------| -| General purpose|[DSv3-series](../dv3-dsv3-series.md#dsv3-series), [Ddsv4-series](../ddv4-ddsv4-series.md#ddsv4-series), [Dsv4-series](../dv4-dsv4-series.md#dsv4-series), [Dasv4-series](../dav4-dasv4-series.md#dasv4-series), [Dsv5-series](../dv5-dsv5-series.md#dsv5-series), [Ddsv5-series](../ddv5-ddsv5-series.md#ddsv5-series), [Dasv5-series](../dasv5-dadsv5-series.md#dasv5-series)| Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers.| -| Compute optimized|[FSv2-series](../fsv2-series.md)| High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes, and application servers.| -| Memory optimized|[ESv3-series](../ev3-esv3-series.md#esv3-series), [Easv4-series](../eav4-easv4-series.md#easv4-series), [Edsv4-series](../edv4-edsv4-series.md#edsv4-series), [Esv4-series](../ev4-esv4-series.md#esv4-series), [Esv5-series](../ev5-esv5-series.md#esv5-series), [Edsv5-series](../edv5-edsv5-series.md#edsv5-series), [Easv5-series](../easv5-eadsv5-series.md#easv5-series), [Ebsv5 series](../ebdsv5-ebsv5-series.md#ebsv5-series), [Ebdsv5 series](../ebdsv5-ebsv5-series.md#ebdsv5-series), [M-series](../m-series.md), [Mv2-series](../mv2-series.md), [Msv2/Mdsv2-series](../msv2-mdsv2-series.md)|High memory-to-CPU ratio. Great for relational database servers, medium to large caches, and in-memory analytics. -| Storage optimized|[LSv2-series](../lsv2-series.md), [Lsv3-series](../lsv3-series.md), [Lasv3-series](../lasv3-series.md)|High disk throughput and IO ideal for Big Data, SQL, NoSQL databases, data warehousing, and large transactional databases.| -| GPU optimized|[NCv2-series](../ncv2-series.md), [NCv3-series](../ncv3-series.md), [NCasT4_v3-series](../nct4-v3-series.md), [ND-series](../nd-series.md), [NDv2-series](../ndv2-series.md), [NVv3-series](../nvv3-series.md), [NVv4-series](../nvv4-series.md), [NVadsA10 v5-series](../nva10v5-series.md)| Specialized virtual machines targeted for heavy graphic rendering and video editing, as well as model training and inferencing (ND) with deep learning. Available with single or multiple GPUs.| -| Performance optimized |[HB-series](../hb-series.md), [HC-series](../hc-series.md), [HBv2-series](../hbv2-series.md)|The fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA).| +| General purpose|[DSv3-series](/azure/virtual-machines/dv3-dsv3-series#dsv3-series), [Ddsv4-series](/azure/virtual-machines/ddv4-ddsv4-series#ddsv4-series), [Dsv4-series](/azure/virtual-machines/dv4-dsv4-series#dsv4-series), [Dasv4-series](/azure/virtual-machines/dav4-dasv4-series#dasv4-series), [Dsv5-series](/azure/virtual-machines/dv5-dsv5-series#dsv5-series), [Ddsv5-series](/azure/virtual-machines/ddv5-ddsv5-series#ddsv5-series), [Dasv5-series](/azure/virtual-machines/dasv5-dadsv5-series#dasv5-series)| Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers.| +| Compute optimized|[FSv2-series](/azure/virtual-machines/fsv2-series)| High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes, and application servers.| +| Memory optimized|[ESv3-series](/azure/virtual-machines/ev3-esv3-series#esv3-series), [Easv4-series](/azure/virtual-machines/eav4-easv4-series#easv4-series), [Edsv4-series](/azure/virtual-machines/edv4-edsv4-series#edsv4-series), [Esv4-series](/azure/virtual-machines/ev4-esv4-series#esv4-series), [Esv5-series](/azure/virtual-machines/ev5-esv5-series#esv5-series), [Edsv5-series](/azure/virtual-machines/edv5-edsv5-series#edsv5-series), [Easv5-series](/azure/virtual-machines/easv5-eadsv5-series#easv5-series), [Ebsv5 series](/azure/virtual-machines/ebdsv5-ebsv5-series#ebsv5-series), [Ebdsv5 series](/azure/virtual-machines/ebdsv5-ebsv5-series#ebdsv5-series), [M-series](/azure/virtual-machines/m-series), [Mv2-series](/azure/virtual-machines/mv2-series), [Msv2/Mdsv2-series](/azure/virtual-machines/msv2-mdsv2-series)|High memory-to-CPU ratio. Great for relational database servers, medium to large caches, and in-memory analytics. +| Storage optimized|[LSv2-series](/azure/virtual-machines/lsv2-series), [Lsv3-series](/azure/virtual-machines/lsv3-series), [Lasv3-series](/azure/virtual-machines/lasv3-series)|High disk throughput and IO ideal for Big Data, SQL, NoSQL databases, data warehousing, and large transactional databases.| +| GPU optimized|[NCv2-series](/azure/virtual-machines/ncv2-series), [NCv3-series](/azure/virtual-machines/ncv3-series), [NCasT4_v3-series](/azure/virtual-machines/nct4-v3-series), [ND-series](/azure/virtual-machines/nd-series), [NDv2-series](/azure/virtual-machines/ndv2-series), [NVv3-series](/azure/virtual-machines/nvv3-series), [NVv4-series](/azure/virtual-machines/nvv4-series), [NVadsA10 v5-series](/azure/virtual-machines/nva10v5-series)| Specialized virtual machines targeted for heavy graphic rendering and video editing, as well as model training and inferencing (ND) with deep learning. Available with single or multiple GPUs.| +| Performance optimized |[HB-series](/azure/virtual-machines/hb-series), [HC-series](/azure/virtual-machines/hc-series), [HBv2-series](/azure/virtual-machines/hbv2-series)|The fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA).| diff --git a/articles/virtual-machines/includes/virtual-machines-disks-encryption-at-host-restrictions.md b/articles/virtual-machines/includes/virtual-machines-disks-encryption-at-host-restrictions.md index 9c3396d25ea..6ac888ecb1f 100644 --- a/articles/virtual-machines/includes/virtual-machines-disks-encryption-at-host-restrictions.md +++ b/articles/virtual-machines/includes/virtual-machines-disks-encryption-at-host-restrictions.md @@ -12,7 +12,7 @@ ms.custom: --- - Supported for 4k sector size Ultra Disks and Premium SSD v2. - Only supported on 512e sector size Ultra Disks and Premium SSD v2 if they were created after 5/13/2023. - - For disks created before this date, [snapshot your disk](../disks-incremental-snapshots.md) and create a new disk using the snapshot. + - For disks created before this date, [snapshot your disk](/azure/virtual-machines/disks-incremental-snapshots) and create a new disk using the snapshot. - Can't be enabled on virtual machines (VMs) or virtual machine scale sets that currently or ever had Azure Disk Encryption enabled. - Azure Disk Encryption can't be enabled on disks that have encryption at host enabled. - The encryption can be enabled on existing virtual machine scale sets. However, only new VMs created after enabling the encryption are automatically encrypted. diff --git a/articles/virtual-machines/includes/virtual-machines-disks-encryption-create-key-vault-portal.md b/articles/virtual-machines/includes/virtual-machines-disks-encryption-create-key-vault-portal.md index 860a825cb97..1676229ab19 100644 --- a/articles/virtual-machines/includes/virtual-machines-disks-encryption-create-key-vault-portal.md +++ b/articles/virtual-machines/includes/virtual-machines-disks-encryption-create-key-vault-portal.md @@ -62,7 +62,7 @@ Now that you've created the Azure key vault and a key, you must add an Azure RBA 1. Make sure **Select Azure key vault and key** is selected. 1. Select the key vault and key you created previously, and the version. -1. If you want to enable [automatic rotation of customer managed keys](../disk-encryption.md#automatic-key-rotation-of-customer-managed-keys), select **Auto key rotation**. +1. If you want to enable [automatic rotation of customer managed keys](/azure/virtual-machines/disk-encryption#automatic-key-rotation-of-customer-managed-keys), select **Auto key rotation**. 1. Select **Review + Create** and then **Create**. :::image type="content" source="media/virtual-machines-disk-encryption-portal/server-side-encryption-disk-set-blade.png" alt-text="Screenshot of the disk encryption creation pane. Showing the subscription, resource group, disk encryption set name, region, and key vault + key selector." lightbox="media/virtual-machines-disk-encryption-portal/server-side-encryption-disk-set-blade.png"::: diff --git a/articles/virtual-machines/includes/virtual-machines-disks-incremental-snapshots-description.md b/articles/virtual-machines/includes/virtual-machines-disks-incremental-snapshots-description.md index be67e8000c0..3f7aa05e54b 100644 --- a/articles/virtual-machines/includes/virtual-machines-disks-incremental-snapshots-description.md +++ b/articles/virtual-machines/includes/virtual-machines-disks-incremental-snapshots-description.md @@ -12,6 +12,6 @@ Incremental snapshots are point-in-time backups for managed disks that, when taken, consist only of the changes since the last snapshot. The first incremental snapshot is a full copy of the disk. The subsequent incremental snapshots occupy only delta changes to disks since the last snapshot. When you restore a disk from an incremental snapshot, the system reconstructs the full disk that represents the point in time backup of the disk when the incremental snapshot was taken. This capability for managed disk snapshots potentially allows them to be more cost-effective, since, unless you choose to, you don't have to store the entire disk with each individual snapshot. Just like full snapshots, incremental snapshots can be used to either create a full managed disk or a full snapshot. Both full snapshots and incremental snapshots can be used immediately after being taken. In other words, once you take either snapshot, you can immediately read the underlying data and use it to restore disks. -There are a few differences between an incremental snapshot and a full snapshot. Incremental snapshots will always use standard HDD storage, irrespective of the storage type of the disk, whereas full snapshots can use premium SSDs. If you're using full snapshots on Premium Storage to scale up VM deployments, we recommend you use custom images on standard storage in the [Azure Compute Gallery](../shared-image-galleries.md). It will help you achieve a more massive scale with lower cost. Additionally, incremental snapshots potentially offer better reliability with [zone-redundant storage](/azure/storage/common/storage-redundancy) (ZRS). If ZRS is available in the selected region, an incremental snapshot will use ZRS automatically. If ZRS isn't available in the region, then the snapshot will default to [locally-redundant storage](/azure/storage/common/storage-redundancy) (LRS). You can override this behavior and select one manually but, we don't recommend that. +There are a few differences between an incremental snapshot and a full snapshot. Incremental snapshots will always use standard HDD storage, irrespective of the storage type of the disk, whereas full snapshots can use premium SSDs. If you're using full snapshots on Premium Storage to scale up VM deployments, we recommend you use custom images on standard storage in the [Azure Compute Gallery](/azure/virtual-machines/shared-image-galleries). It will help you achieve a more massive scale with lower cost. Additionally, incremental snapshots potentially offer better reliability with [zone-redundant storage](/azure/storage/common/storage-redundancy) (ZRS). If ZRS is available in the selected region, an incremental snapshot will use ZRS automatically. If ZRS isn't available in the region, then the snapshot will default to [locally redundant storage](/azure/storage/common/storage-redundancy) (LRS). You can override this behavior and select one manually but, we don't recommend that. Incremental snapshots are billed for the used size only. You can find the used size of your snapshots by looking at the [Azure usage report](/azure/cost-management-billing/understand/review-individual-bill). For example, if the used data size of a snapshot is 10 GiB, the **daily** usage report will show 10 GiB/(31 days) = 0.3226 as the consumed quantity. diff --git a/articles/virtual-machines/includes/virtual-machines-disks-incremental-snapshots-restrictions.md b/articles/virtual-machines/includes/virtual-machines-disks-incremental-snapshots-restrictions.md index 6679e44c876..96c66a1a5fe 100644 --- a/articles/virtual-machines/includes/virtual-machines-disks-incremental-snapshots-restrictions.md +++ b/articles/virtual-machines/includes/virtual-machines-disks-incremental-snapshots-restrictions.md @@ -17,7 +17,7 @@ - Up to seven incremental snapshots per disk can be created every five minutes. - A total of 500 incremental snapshots can be created for a single disk. The 500 quota limit is not over the lifetime of a disk, but at any given point in time. You can always delete older snapshots of a disk to make room for newer snapshots. - You can't get the changes between snapshots taken before and after you changed the size of the parent disk across 4-TB boundary. For example, You took an incremental snapshot `snapshot-a` when the size of a disk was 2 TB. Now you increased the size of the disk to 6 TB and then took another incremental snapshot `snapshot-b`. You can't get the changes between `snapshot-a` and `snapshot-b`. You have to download the full copy of `snapshot-b` created after the resize. Subsequently, you can get the changes between `snapshot-b` and snapshots created after `snapshot-b`. -- When you create a managed disk from a snapshot, it starts a background copy process. You can attach a disk to a VM while this process is running but you'll experience [performance impact](../premium-storage-performance.md#latency). You can use CompletionPercent property to [check the status of the background copy](../scripts/create-managed-disk-from-snapshot.md#performance-impact---background-copy-process) for Ultra Disks and Premium SSD v2 disks. +- When you create a managed disk from a snapshot, it starts a background copy process. You can attach a disk to a VM while this process is running but you'll experience [performance impact](/azure/virtual-machines/premium-storage-performance#latency). You can use CompletionPercent property to [check the status of the background copy](/azure/virtual-machines/scripts/create-managed-disk-from-snapshot#performance-impact---background-copy-process) for Ultra Disks and Premium SSD v2 disks. ### Incremental snapshots of Premium SSD v2 and Ultra Disks @@ -29,7 +29,7 @@ Incremental snapshots of Premium SSD v2 and Ultra Disks have the following extra - Incremental snapshots of a Premium SSD v2 or an Ultra disk can't be used immediately after they're created. The background copy must complete before you can create a disk from the snapshot. See [Check snapshot status](#check-snapshot-status) for details. - Taking increment snapshots of a Premium SSD v2 or an Ultra disk while the CompletionPercent property of the disk hasn't reached 100 isn't supported. - When you increase the size of a Premium SSD v2 or an Ultra disk, any incremental snapshots that are under background copy will fail. -- When you attach a Premium SSD v2 or Ultra disk created from snapshot to a running Virtual Machine while CompletionPercent property hasn't reached 100, the disk suffers performance impact. Specifically, if the disk has a 4k sector size, it may experience slower read. If the disk has a 512e sector size, it may experience slower read and write. To track the progress of this background copy process, see the the check disk status section of either the Azure [PowerShell sample](../scripts/virtual-machines-powershell-sample-create-managed-disk-from-snapshot.md#performance-impact---background-copy-process) or the [Azure CLI](../scripts/create-managed-disk-from-snapshot.md#performance-impact---background-copy-process). +- When you attach a Premium SSD v2 or Ultra disk created from snapshot to a running Virtual Machine while CompletionPercent property hasn't reached 100, the disk suffers performance impact. Specifically, if the disk has a 4k sector size, it may experience slower read. If the disk has a 512e sector size, it may experience slower read and write. To track the progress of this background copy process, see the check disk status section of either the Azure [PowerShell sample](/azure/virtual-machines/scripts/virtual-machines-powershell-sample-create-managed-disk-from-snapshot#performance-impact---background-copy-process) or the [Azure CLI](/azure/virtual-machines/scripts/virtual-machines-powershell-sample-create-managed-disk-from-snapshot#performance-impact---background-copy-process). > [!NOTE] > Normally, when you take an incremental snapshot, and there aren't any changes, the size of that snapshot is 0 MiB. Currently, empty snapshots of disks with a 4096 logical sector size instead have a size of 6 MiB, when they'd normally be 0 MiB. diff --git a/articles/virtual-machines/includes/virtual-machines-disks-performance-tiers-intro.md b/articles/virtual-machines/includes/virtual-machines-disks-performance-tiers-intro.md index 345d3f526bf..44094357ae6 100644 --- a/articles/virtual-machines/includes/virtual-machines-disks-performance-tiers-intro.md +++ b/articles/virtual-machines/includes/virtual-machines-disks-performance-tiers-intro.md @@ -11,8 +11,8 @@ --- > [!NOTE] -> This article focuses on how to change performance tiers. To learn how to change the performance of disks that don't use performance tiers, like Ultra Disks or Premium SSD v2, see either [Adjust the performance of an ultra disk](../disks-enable-ultra-ssd.md#adjust-the-performance-of-an-ultra-disk) or [Adjust disk performance of a Premium SSD v2](../disks-deploy-premium-v2.md#adjust-disk-performance) +> This article focuses on how to change performance tiers. To learn how to change the performance of disks that don't use performance tiers, like Ultra Disks or Premium SSD v2, see either [Adjust the performance of an ultra disk](/azure/virtual-machines/disks-enable-ultra-ssd?tabs=azure-portal#adjust-the-performance-of-an-ultra-disk) or [Adjust disk performance of a Premium SSD v2](/azure/virtual-machines/disks-deploy-premium-v2?tabs=azure-cli#adjust-disk-performance) -The performance of your Azure managed disk is set when you create your disk, in the form of its performance tier. The performance tier determines the IOPS and throughput your managed disk has. When you set the provisioned size of your disk, a performance tier is automatically selected. The performance tier can be changed at deployment or afterwards, without changing the size of the disk and without downtime. To learn more about performance tiers, see [Performance tiers for managed disks](../disks-change-performance.md). +The performance of your Azure managed disk is set when you create your disk, in the form of its performance tier. The performance tier determines the IOPS and throughput your managed disk has. When you set the provisioned size of your disk, a performance tier is automatically selected. The performance tier can be changed at deployment or afterwards, without changing the size of the disk and without downtime. To learn more about performance tiers, see [Performance tiers for managed disks](/azure/virtual-machines/disks-change-performance). -Changing your performance tier has billing implications. See [Billing impact](../disks-change-performance.md#billing-impact) for details. \ No newline at end of file +Changing your performance tier has billing implications. See [Billing impact](/azure/virtual-machines/disks-change-performance#billing-impact) for details. \ No newline at end of file diff --git a/articles/virtual-machines/includes/virtual-machines-disks-shared-limitations.md b/articles/virtual-machines/includes/virtual-machines-disks-shared-limitations.md index 948d5c2655d..63cba5aabbf 100644 --- a/articles/virtual-machines/includes/virtual-machines-disks-shared-limitations.md +++ b/articles/virtual-machines/includes/virtual-machines-disks-shared-limitations.md @@ -12,7 +12,7 @@ ### General limitations -Shared disks have general limitations that apply to all shared disks, regardless of disk type. As well as additional limitations that only apply to specific types of shared disks. The following list is the list of general limitations: +Shared disks have general limitations that apply to all shared disks, regardless of disk type. They also have more limitations that only apply to specific types of shared disks. The following list is the list of general limitations: - Currently, only Ultra Disks, Premium SSD v2, Premium SSD, and Standard SSDs can be used as a shared disk - Shared disks can be attached to individual Virtual Machine Scale Sets but can't be defined in the Virtual Machine Scale Set models or automatically deployed @@ -24,7 +24,7 @@ Each managed disk that has shared disks enabled are also subject to the followin ### Ultra disks -Ultra disks have their own separate list of limitations, unrelated to shared disks. For ultra disk limitations, refer to [Using Azure ultra disks](../disks-enable-ultra-ssd.md). +Ultra disks have their own separate list of limitations, unrelated to shared disks. For ultra disk limitations, refer to [Using Azure ultra disks](/azure/virtual-machines/disks-enable-ultra-ssd). When sharing ultra disks, they have the following additional limitations: @@ -34,7 +34,7 @@ When sharing ultra disks, they have the following additional limitations: ### Premium SSD v2 -Premium SSD v2 managed disks have their own separate list of limitations, unrelated to shared disks. For these limitations, see [Premium SSD v2 limitations](../disks-types.md#premium-ssd-v2-limitations). +Premium SSD v2 managed disks have their own separate list of limitations, unrelated to shared disks. For these limitations, see [Premium SSD v2 limitations](/azure/virtual-machines/disks-types#premium-ssd-v2-limitations). When sharing Premium SSD v2 disks, they have the following additional limitation: @@ -46,22 +46,22 @@ When sharing Premium SSD v2 disks, they have the following additional limitation - Can only be enabled on data disks, not OS disks. - Host caching isn't available for premium SSD disks with `maxShares>1`. - Disk bursting isn't available for premium SSD disks with `maxShares>1`. -- When using Availability sets or Virtual Machine Scale Sets with Azure shared disks, [storage fault domain alignment](../availability.md) with virtual machine fault domain isn't enforced for the shared data disk. -- When using [proximity placement groups (PPG)](../windows/proximity-placement-groups.md), all virtual machines sharing a disk must be part of the same PPG. +- When using Availability sets or Virtual Machine Scale Sets with Azure shared disks, [storage fault domain alignment](/azure/virtual-machines/availability) with virtual machine fault domain isn't enforced for the shared data disk. +- When using [proximity placement groups (PPG)](/azure/virtual-machines/windows/proximity-placement-groups), all virtual machines sharing a disk must be part of the same PPG. - Only basic disks can be used with some versions of Windows Server Failover Cluster, for details see [Failover clustering hardware requirements and storage options](/windows-server/failover-clustering/clustering-requirements). - Azure Site Recovery support isn't yet available. - Azure Backup is available through [Azure Disk Backup](/azure/backup/disk-backup-overview). -- Only [server-side encryption](../disk-encryption.md) is supported, [Azure Disk Encryption](../windows/disk-encryption-overview.md) isn't currently supported. -- Can only be shared across availability zones if using [Zone-redundant storage for managed disks](../disks-redundancy.md#zone-redundant-storage-for-managed-disks). +- Only [server-side encryption](/azure/virtual-machines/disk-encryption) is supported, [Azure Disk Encryption](/azure/virtual-machines/disk-encryption-overview) isn't currently supported. +- Can only be shared across availability zones if using [Zone-redundant storage for managed disks](/azure/virtual-machines/disks-redundancy#zone-redundant-storage-for-managed-disks). ### Standard SSDs - Can only be enabled on data disks, not OS disks. - Host caching isn't available for standard SSDs with `maxShares>1`. -- When using Availability sets and Virtual Machine Scale Sets with Azure shared disks, [storage fault domain alignment](../availability.md) with virtual machine fault domain isn't enforced for the shared data disk. -- When using [proximity placement groups (PPG)](../windows/proximity-placement-groups.md), all virtual machines sharing a disk must be part of the same PPG. +- When using Availability sets and Virtual Machine Scale Sets with Azure shared disks, [storage fault domain alignment](/azure/virtual-machines/availability) with virtual machine fault domain isn't enforced for the shared data disk. +- When using [proximity placement groups (PPG)](/azure/virtual-machines/windows/proximity-placement-groups), all virtual machines sharing a disk must be part of the same PPG. - Only basic disks can be used with some versions of Windows Server Failover Cluster, for details see [Failover clustering hardware requirements and storage options](/windows-server/failover-clustering/clustering-requirements). - Azure Site Recovery support isn't yet available. - Azure Backup is available through [Azure Disk Backup](/azure/backup/disk-backup-overview). -- Only [server-side encryption](../disk-encryption.md) is supported, [Azure Disk Encryption](../windows/disk-encryption-overview.md) isn't currently supported. -- Can only be shared across availability zones if using [Zone-redundant storage for managed disks](../disks-redundancy.md#zone-redundant-storage-for-managed-disks). +- Only [server-side encryption](/azure/virtual-machines/disk-encryption) is supported, [Azure Disk Encryption](/azure/virtual-machines/disk-encryption-overview) isn't currently supported. +- Can only be shared across availability zones if using [Zone-redundant storage for managed disks](/azure/virtual-machines/disks-redundancy#zone-redundant-storage-for-managed-disks). diff --git a/articles/virtual-machines/includes/virtual-machines-managed-disks-customer-managed-keys-restrictions.md b/articles/virtual-machines/includes/virtual-machines-managed-disks-customer-managed-keys-restrictions.md index 7bfd05beb1c..257e2a1e288 100644 --- a/articles/virtual-machines/includes/virtual-machines-managed-disks-customer-managed-keys-restrictions.md +++ b/articles/virtual-machines/includes/virtual-machines-managed-disks-customer-managed-keys-restrictions.md @@ -9,7 +9,7 @@ ms.custom: include file --- - If this feature is enabled for a disk with incremental snapshots, it can't be disabled on that disk or its snapshots. - To work around this, copy all the data to an entirely different managed disk that isn't using customer-managed keys. You can do that with either the [Azure CLI](../linux/disks-upload-vhd-to-managed-disk-cli.md#copy-a-managed-disk) or the [Azure PowerShell module](../windows/disks-upload-vhd-to-managed-disk-powershell.md#copy-a-managed-disk). + To work around this, copy all the data to an entirely different managed disk that isn't using customer-managed keys. You can do that with either the [Azure CLI](/azure/virtual-machines/linux/disks-upload-vhd-to-managed-disk-cli#copy-a-managed-disk) or the [Azure PowerShell module](/azure/virtual-machines/windows/disks-upload-vhd-to-managed-disk-powershell#copy-a-managed-disk). - Only [software and HSM RSA keys](/azure/key-vault/keys/about-keys) of sizes 2,048-bit, 3,072-bit and 4,096-bit are supported, no other keys or sizes. - [HSM](/azure/key-vault/keys/hsm-protected-keys) keys require the **premium** tier of Azure Key vaults. - For Ultra Disks and Premium SSD v2 disks only: @@ -17,9 +17,9 @@ - User-assigned managed identities aren't supported for Ultra Disks and Premium SSD v2 disks encrypted with customer-managed keys. - Not currently supported in Azure Government or Azure China. - Most resources related to your customer-managed keys (disk encryption sets, VMs, disks, and snapshots) must be in the same subscription and region. - - Azure Key Vaults may be used from a different subscription but must be in the same region as your disk encryption set. As a preview, you can use Azure Key Vaults from [different Microsoft Entra tenants](../disks-cross-tenant-customer-managed-keys.md). + - Azure Key Vaults may be used from a different subscription but must be in the same region as your disk encryption set. As a preview, you can use Azure Key Vaults from [different Microsoft Entra tenants](/azure/virtual-machines/disks-cross-tenant-customer-managed-keys). - Disks encrypted with customer-managed keys can only move to another resource group if the VM they are attached to is deallocated. - Disks, snapshots, and images encrypted with customer-managed keys can't be moved between subscriptions. - Managed disks currently or previously encrypted using Azure Disk Encryption can't be encrypted using customer-managed keys. - Can only create up to 5000 disk encryption sets per region per subscription. -- For information about using customer-managed keys with shared image galleries, see [Preview: Use customer-managed keys for encrypting images](../image-version-encryption.md). +- For information about using customer-managed keys with shared image galleries, see [Preview: Use customer-managed keys for encrypting images](/azure/virtual-machines/image-version-encryption). diff --git a/articles/virtual-machines/sizes/gpu-accelerated/ndmi300xv5-series.md b/articles/virtual-machines/sizes/gpu-accelerated/ndmi300xv5-series.md index 33000d71b93..f76e2749dba 100644 --- a/articles/virtual-machines/sizes/gpu-accelerated/ndmi300xv5-series.md +++ b/articles/virtual-machines/sizes/gpu-accelerated/ndmi300xv5-series.md @@ -47,7 +47,7 @@ Remote (uncached) storage info for each size | Size Name | Max Remote Storage Disks (Qty.) | Uncached Disk IOPS | Uncached Disk Speed (MBps) | Uncached Disk Burst1 IOPS | Uncached Disk Burst1 Speed (MBps) | Uncached Special2 Disk IOPS | Uncached Special2 Disk Speed (MBps) | Uncached Burst1 Special2 Disk IOPS | Uncached Burst1 Special2 Disk Speed (MBps) | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| Standard_ND96isr_MI300X_v5 | 32 | 40800 | 612 | | | | | | | +| Standard_ND96isr_MI300X_v5 | 16 | 40800 | 612 | | | | | | | #### Storage resources - [Introduction to Azure managed disks](../../../virtual-machines/managed-disks-overview.md) diff --git a/articles/virtual-machines/windows/n-series-amd-driver-setup.md b/articles/virtual-machines/windows/n-series-amd-driver-setup.md index c1710e82db2..554c549255f 100644 --- a/articles/virtual-machines/windows/n-series-amd-driver-setup.md +++ b/articles/virtual-machines/windows/n-series-amd-driver-setup.md @@ -55,8 +55,8 @@ For basic specs, storage capacities, and disk details, see [GPU Windows VM sizes | OS | Driver | | -------- |------------- | | Windows 11 64-bit 21H2, 22H2, 23H2

Windows 10 64-bit 21H2, 22H2, 20H2

| [23.Q3](https://download.microsoft.com/download/0/8/1/081db0c3-d2c0-44ae-be45-90a63610b16e/AMD-Azure-NVv4-Driver-23Q3-win10-win11.exe) (.exe) | -| Windows Server 2022

| [23.Q3](https://download.microsoft.com/download/2/d/3/2d328d15-4188-4fdb-8912-fb300a212dfc/AMD-Azure-NVv4-Driver-23Q3-winsvr2022.exe) (.exe) -| Windows Server 2019

| [23.Q3](https://download.microsoft.com/download/e/8/8/e88bb244-b8e8-47cc-9f86-9ba2632b3cb6/AMD-Azure-NVv4-Driver-23Q3-winsvr2019.exe) (.exe) +| Windows Server 2022, Windows 11 EMS

| [23.Q3](https://download.microsoft.com/download/2/d/3/2d328d15-4188-4fdb-8912-fb300a212dfc/AMD-Azure-NVv4-Driver-23Q3-winsvr2022.exe) (.exe) +| Windows Server 2019, Windows 10 EMS

| [23.Q3](https://download.microsoft.com/download/e/8/8/e88bb244-b8e8-47cc-9f86-9ba2632b3cb6/AMD-Azure-NVv4-Driver-23Q3-winsvr2019.exe) (.exe) Previous supported driver versions for Windows builds up to 1909 are [20.Q4-1](https://download.microsoft.com/download/0/e/6/0e611412-093f-40b8-8bf9-794a1623b2be/AMD-Azure-NVv4-Driver-20Q4-1.exe) (.exe) and [21.Q2-1](https://download.microsoft.com/download/4/e/a/4ea28d3f-28e2-4eaa-8ef2-4f7d32882a0b/AMD-Azure-NVv4-Driver-21Q2-1.exe) (.exe) @@ -68,6 +68,15 @@ Previous supported driver versions for Windows builds up to 1909 are [20.Q4-1](h ### Driver installation +> [!NOTE] + > Follow these steps if you see "Error 184 - AMD Installer cannot cpontinue due to an unsupported Operating System" error on Windows 10 EMS / Windows 11 EMS. + > + > Go to C:\AMD\AMD Software Azure NVv4 Guest Driver 23Q3\Packages\Drivers\Display\WT6A_INF + > Right click and install on the *.inf file. + > + > For Windows10 EMS: u9397288.inf + > + > For Windows11 EMS: u2397344.inf 1. Connect by Remote Desktop to each NVv4-series VM.