You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/virtual-machines/msv2-mdsv2-migration-guide.md
+62Lines changed: 62 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,3 +15,65 @@ ms.date: 01/10/2024
15
15
16
16
# Msv2 and Mdsv2 Migration Guide
17
17
18
+
On March 31, 2027, Azure will retire the Msv2 and Mdsv2-series Medium Memory virtual machines (VM) listed below:
19
+
20
+
- Msv2 Medium Memory Diskless
21
+
22
+
- Standard_M192is_v2
23
+
24
+
- Standard_M192ims_v2
25
+
26
+
- Mdsv2 Medium Memory with Disk
27
+
28
+
- Standard_M192ids_v2
29
+
30
+
- Standard_M192idms_v2
31
+
32
+
From now to March 31, 2027, you can continue to use the VMs listed above without disruption. On March 31, 2027, the remaining VMs with these specific sizes on your subscription will be set to a deallocated state. These VMs will be stopped and removed from the host. These VMs will no longer be billed in the deallocated state. To avoid service disruptions, please follow our instructions below to migrate to your selected Mv3 replacement size by March 31, 2027.
33
+
34
+
#### Migrate workloads to Mv3 Medium Memory Series VMs
35
+
36
+
The [Msv3 and Mdsv3 Medium Memory Series](/azure/virtual-machines/msv3-mdsv3-medium-series), powered by 4th generation Intel® Xeon® Scalable processors, are the next generation of memory-optimized VM sizes delivering faster performance, lower total cost of ownership and improved resilience to failures compared to previous generation Mv2 VMs. The Mv3 MM series offers VM sizes of up to 4TB of memory and 4,000 MBps throughout to remote storage and provides up to 25% networking performance improvements over previous generations.
37
+
38
+
Follow the instructions below to migrate your [M192i(d)(m)s VM](/azure/virtual-machines/msv2-mdsv2-series) to your chosen [Msv3 and Mdsv3 Medium Memory Series](/azure/virtual-machines/msv3-mdsv3-medium-series) replacement.
39
+
40
+
### Migration Steps
41
+
42
+
Choose a [series and size](/azure/virtual-machines/msv3-mdsv3-medium-series) for migration. Leverage the [pricing calculator](https://azure.microsoft.com/en-us/pricing/calculator/) for further insights.
43
+
44
+
[Get quota for the target VM series](/azure/quotas/per-vm-quota-requests).
45
+
46
+
Check whether the existing M192i(d)(m)s VM is part of an [Availability Set](/azure/virtual-machines/availability-set-overview) or [Proximity Placement Group](/azure/virtual-machines/co-location). You can check in Azure Portal in the VM properties.
47
+
48
+
If the VM is not part of an Availability Set nor a Proximity Placement Group, [it can be resized](/azure/virtual-machines/resize-vm?tabs=portal).
49
+
50
+
If the VM is part of an Availability Set, check your records to determine whether you asked Microsoft to pin the Availability Set to a specific M-series compute cluster for proximity purposes (e.g. to collocate with services like NFS shares hosted on Azure NetApp Files). If you are not sure about pinning having taken place, open an [Azure Support Request](https://ms.portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/newsupportrequest) to confirm.
51
+
52
+
If your VM is part of a non-pinned Availability Set, you need to shut down all VMs in that particular Availability Set and go through the [resize procedure](/azure/virtual-machines/resize-vm?tabs=portal) for every single VM of the Availability Set.
53
+
54
+
If the VM or Availability Set is part of a Proximity Placement Group, it is recommended to switch availability options to [zonal deployment](/azure/reliability/availability-zones-overview?toc=%2Fazure%2Fvirtual-machines%2Ftoc.json&tabs=azure-cli) using the script linked below or setting up Database Replication (e.g. HANA System Replication, SQL Server AlwaysOn). Zonal deployments significantly reduce the possibility of allocation failure.
55
+
56
+
[How to Migrate a Highly Available SAP System in Azure from Availability Set to Availability Zone](https://github.com/Azure/SAP-on-Azure-Scripts-and-Utilities/tree/main/Move-VM-from-AvSet-to-AvZone/Move-Regional-SAP-HA-To-Zonal-SAP-HA-WhitePaper)
57
+
58
+
If your VM is part of a pinned Availability set or if you cannot switch your availability option to Availability Zone (as recommended in step 5 above), open an Azure Support request to assist with resizing.
59
+
60
+
### Help and support
61
+
62
+
If you have questions, ask community experts in [Microsoft Q&A](/answers/topics/azure-virtual-machines.html). If you have a support plan and need technical help, create a support request:
63
+
64
+
In the [Help + support page](https://ms.portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/newsupportrequest), select Create a support request. Follow the New support request page instructions. Use the following values:
65
+
66
+
For Issue type, select Technical.
67
+
68
+
For Service, select My services.
69
+
70
+
For Service type, select Virtual Machine running Windows/Linux or Virtual Machine running SAP in case you run SAP application workloads.
71
+
72
+
For Resource, select your VM.
73
+
74
+
For Problem type, select Assistance with resizing my VM.
75
+
76
+
For Problem subtype, select the option that applies to you.
77
+
78
+
Follow instructions in the Solutions and Details tabs, as applicable, and then Review + create.
0 commit comments