Disco temporal, controladora SCSI/NVMe, licencias Windows y Azure-SSIS IR todo lo que necesitas saber antes de mover una sola VM
Artículo técnico
Por qué Microsoft retira series de VM (y qué significa para ti)
En los últimos doce meses Microsoft ha publicado un número inusualmente alto de anuncios de retirada de series de máquinas virtuales. No es casualidad: el hardware que ejecuta esas familias ha alcanzado el fin de su vida útil, los fabricantes de procesadores ya no ofrecen soporte extendido y la brecha de rendimiento por euro respecto a las generaciones actuales se ha vuelto difícil de justificar. La consecuencia práctica es simple y directa: el día que una serie entra en estado Retired, las VM existentes quedan desasignadas, dejan de funcionar, pierden el SLA y dejan de facturarse — pero los datos en disco administrado se conservan. Si no actúas antes de la fecha límite, tus cargas de trabajo se paran sin previo aviso.
Este artículo responde a una pregunta concreta que nos plantean habitualmente clientes y partners: ¿cómo hago el resize de forma segura? La respuesta no es trivial. Hay al menos cuatro trampas que pueden romper una migración aparentemente sencilla: la disponibilidad (o ausencia) de disco temporal, el cambio de controladora de disco de SCSI a NVMe en las familias v6 en adelante, el incremento de coste al abandonar la B-series, y el impacto en los Integration Runtime de Azure Data Factory. Vamos a ver todo esto con detalle.
Fechas clave: las series D, Ds, Dv2, Dsv2 y Ls se retiran el 01/05/2028. Las series Av2, Amv2, Bv1, F, Fs, Fsv2, G, Gs y Lsv2 se retiran el 15/11/2028. NVv3 y NVv4 se retiran el 30/09/2026. NP-series, HBv2 y HC-series el 31/05/2027. Los SKUs M192 (Msv2/Mdsv2) el 31/03/2027. Fuente: learn.microsoft.com/azure/virtual-machines/sizes/retirement/retired-sizes-list
Series afectadas y sus reemplazos oficiales
La siguiente tabla consolida la información publicada por Microsoft en la página oficial de series retiradas y en las guías de migración de cada familia. El estado ‘Announced’ significa que la serie sigue disponible pero tiene fecha de corte; el estado ‘Retired’ implica que ya no se puede aprovisionar.
Nota: la migration guide d-ds-dv2-dsv2-ls-series-migration-guide cubre también HBv2 en una sección específica. HC-series tiene su propia página de retiro en learn.microsoft.com/azure/virtual-machines/sizes/retirement/hc-series-retirement.
Guías de migración por familia: lo esencial de cada una
Microsoft ha publicado guías de migración específicas para cada grupo de series. A continuación resumimos los puntos operativos más relevantes, basándonos en la documentación oficial.
D, Ds, Dv2, Dsv2, Av2, Amv2, Bv1, F, Fs, Fsv2, G, Gs, Ls, Lsv2 — y HBv2
Todas estas series comparten la misma guía de migración unificada publicada el 30 de enero de 2026 incluyendo HBv2, cuyo retiro también se documenta allí. El proceso recomendado es:
1. Revisar las reservas de instancias (RI) activas: las compras de RI de 1 y 3 años para estas series no se pueden renovar tras el 1 de julio de 2026. Si tienes RIs activas, puedes canjearlas por nuevas series o convertirlas en un Azure Savings Plan for Compute sin penalización.
2. Identificar el tamaño objetivo usando la tabla de reemplazos de la guía oficial. Presta atención a si el reemplazo elegido es v5 (SCSI) o v6/v7 (NVMe) esa diferencia condiciona todo el proceso.
3. Solicitar cuota para la serie objetivo antes de iniciar el resize. Verifica que tu suscripción tiene cuota suficiente en portal.azure.com > Suscripción > Uso y cuotas.
4. Detener (desasignar) la VM.
5. Cambiar el tamaño mediante portal, CLI o PowerShell (ver sección de guía operativa).
6. Arrancar la VM y validar.
Atención con Dv3, Dsv3, Ev3, Esv3: estas series NO están en proceso de retiro todavía, pero Microsoft ha anunciado que las RI de 1 y 3 años dejarán de estar disponibles para nuevas compras o renovaciones tras el 1 de julio de 2026. Si planeas continuar usándolas, el Azure Savings Plan for Compute es la alternativa recomendada.
La guía unificada lista como targets tanto series v5 (SCSI) como v6 y v7 (NVMe). Para cargas de trabajo D-series, los objetivos documentados incluyen Dsv5, Ddsv5, Dasv5, Dadsv5 (SCSI) y Dasv6, Dadsv6, Dsv6, Ddsv6, Dasv7, Dadsv7 (NVMe).
Nota: las series v7 requieren NVMe y OS Gen2 compatible, igual que v6. Verifica disponibilidad regional antes de seleccionarlas como objetivo.
HBv2 serie HPC (retiro 31/05/2027, confirmado)
Los SKUs afectados son Standard_HB120rs_v2 y sus variantes con vCPUs restringidas (Standard_HB120-96rs_v2, Standard_HB120-64rs_v2, Standard_HB120-32rs_v2, Standard_HB120-16rs_v2). Estas VMs ofrecen 120 cores AMD EPYC 7V12 (Rome) y 200 Gb/s InfiniBand HDR. Las compras de RI de 1 y 3 años terminaron el 2 de abril de 2026.
Microsoft documenta los siguientes reemplazos en orden de preferencia según el tipo de workload:
- HBv5-series AMD EPYC Genoa; mayor bandwidth de memoria, InfiniBand NDR; primera opción para la mayoría de workloads.
- HX-series alta densidad de memoria con InfiniBand NDR; idóneo para molecular dynamics y alta capacidad de RAM.
- HBv4-series AMD EPYC Genoa, InfiniBand NDR; equilibrio precio-rendimiento.
- HBv3-series AMD EPYC Milan, InfiniBand HDR (mismo fabric que HBv2); migración de menor impacto para workloads InfiniBand-dependientes.
La selección entre estos reemplazos debe validarse teniendo en cuenta: compatibilidad MPI y fabric InfiniBand (HDR en HBv2 y HBv3 frente a NDR en HBv4/HBv5), benchmark de bandwidth de memoria en el workload real, y disponibilidad de capacidad en la región objetivo. La documentación oficial recomienda explícitamente realizar test de validación de workload MPI antes de migrar a producción.
HC-series serie HPC (retiro 31/05/2027, confirmado)
Los SKUs afectados son Standard_HC44rs, Standard_HC44-16rs y Standard_HC44-32rs. Estas VMs incluyen 44 cores Intel Xeon Platinum 8168 (Skylake), 352 GB de memoria y 100 Gb/s InfiniBand EDR. Las compras de RI terminaron el 2 de abril de 2026, igual que HBv2.
Microsoft recomienda dos reemplazos para HC-series en su página oficial de la serie y en la guía de retiro específica (learn.microsoft.com/azure/virtual-machines/sizes/retirement/hc-series-retirement):
- HBv5-series: mayor rendimiento de cómputo y mejor precio-rendimiento que HBv4; adecuado para la mayoría de workloads HPC memory-bandwidth intensivos.
- HX-series: optimizado para workloads HPC con alta capacidad de memoria, con aproximadamente el doble de capacidad de memoria que HBv4; idóneo para EDA a gran escala y dinámica molecular.
Nota: HC-series no aparece en el índice principal retired-sizes-list, que solo lista HBv2 en la sección HPC. El retiro de HC está documentado en dos páginas específicas: la página de la serie (learn.microsoft.com/azure/virtual-machines/sizes/high-performance-compute/hc-series) y la guía de retiro dedicada (learn.microsoft.com/azure/virtual-machines/sizes/retirement/hc-series-retirement). Esas páginas son la fuente autoritativa para HC documentan el retiro del 31/05/2027, el impacto de la desasignación y las alternativas HPC recomendadas.
Msv2 / Mdsv2 — SKUs M192 (retiro 31/03/2027)
Los SKUs afectados son Standard_M192is_v2, Standard_M192ims_v2, Standard_M192ids_v2 y Standard_M192idms_v2. La guía oficial establece un proceso más complejo por las posibles dependencias con Availability Sets y Proximity Placement Groups (PPG, grupos de colocación por proximidad). Los pasos son:
1. Verificar si la VM forma parte de un Availability Set o de un PPG (visible en las propiedades de la VM en el portal).
2. Si NO forma parte de ninguno, el resize directo está soportado.
3. Si forma parte de un PPG pero no de un Availability Set: detener todas las VMs del PPG, hacer el resize de las M192 y reiniciar el resto.
4. Si forma parte de un Availability Set NO anclado: detener TODAS las VMs del Availability Set y hacer el resize de cada una.
5. Si el Availability Set está anclado a un clúster M-series específico (habitual cuando se comparte almacenamiento NFS con Azure NetApp Files): abrir un ticket de soporte — Microsoft gestiona estos casos manualmente.
6. La serie de reemplazo recomendada es Msv3 / Mdsv3 Medium Memory, basada en procesadores Intel Xeon 4ª generación, con hasta 4 TB de memoria y 4.000 MBps a almacenamiento remoto.
NVv3 y NVv4 series GPU (retiro 30/09/2026, urgente)
Estas dos series tienen la fecha de retiro más próxima entre las que siguen activas: el 30 de septiembre de 2026. Las RI de 1 y 3 años ya no se podían comprar desde noviembre de 2025.
Reemplazos recomendados para NVv3 (NVIDIA Tesla M60):
- NVads_A10_v5 GPU NVIDIA A10, idóneo para workloads gráficos y VDI de alto rendimiento.
- NVads_V710_v5 GPU AMD Radeon PRO V710, opción económica para VDI y gráficos ligeros.
Reemplazos recomendados para NVv4 (AMD Radeon Instinct MI25):
- NVads_V710_v5 Microsoft lo recomienda para todos los escenarios de NVv4 (gráficos, VDI, small AI). Existe un error conocido al migrar de NVv4 a NVads_V710_v5 mediante operación de resize directo; Microsoft está trabajando en el fix. Como workaround, la guía oficial remite al procedimiento de migración entre VM con y sin disco temporal.
NP-series FPGA (retiro 31/05/2027)
Los SKUs Standard_NP10s, Standard_NP20s y Standard_NP40s utilizan FPGAs AMD Xilinx Alveo U250. La migración a cualquiera de los reemplazos (NDv2, NCads_H100_v5, NCasT4_v3) requiere portar las cargas de trabajo de frameworks FPGA (Vitis/XRT) a frameworks GPU (CUDA). Esto no es un resize transparente es una migración de aplicación que puede requerir semanas de trabajo. Las compras de RI para NP-series terminaron el 2 de abril de 2026.
Consideraciones operativas críticas
Aquí es donde la mayoría de los proyectos de migración se complican. Vamos a ver en detalle los cuatro factores que más preguntas generan en proyectos reales.
Disco temporal: ¿lo tiene o no lo tiene?
La familia v5 introdujo una división que no existía en generaciones anteriores: los SKUs sin «d» en el nombre (Dv5, Dsv5, Dasv5, Ev5, Esv5, Easv5) no tienen disco temporal local. Los SKUs con «d» (Ddv5, Ddsv5, Dadsv5, Edv5, Edsv5, Eadsv5) sí incluyen disco temporal local en la familia v5 se trata de local SSD con controladora SCSI, no NVMe. Si migras de una VM de generación anterior que usaba la unidad D: como disco temporal y eliges un SKU sin «d», el sistema operativo no encontrará ese disco y pueden ocurrir varias cosas malas:
- Windows: el archivo de paginación (pagefile.sys) desaparece → crash potencial al agotar RAM.
- SQL Server: el tempdb configurado en la unidad D: no arranca → instancia SQL no disponible.
- Aplicaciones: cualquier ruta hardcodeada a D:\ falla en el primer arranque.
- Linux: el swap configurado en /dev/sdb (resource disk) deja de estar disponible.
La documentación oficial establece una restricción importante en Windows: no se puede hacer un resize directo entre una VM con disco temporal y una sin él, ni viceversa. Las únicas combinaciones permitidas mediante resize son disco a disco y diskless a diskless. Fuente: learn.microsoft.com/azure/virtual-machines/azure-vms-no-temp-disk y learn.microsoft.com/azure/virtual-machines/sizes/resize-vm. Para cruzar esa frontera en Windows, el procedimiento oficial es:
1. Conectarse a la VM actual como administrador local.
2. Mover el pagefile.sys de D: a C: siguiendo la guía ‘Use the D: drive as a data drive on a Windows VM’ (learn.microsoft.com/azure/virtual-machines/windows/change-drive-letter).
3. Tomar un snapshot del disco OS.
4. Crear la nueva VM diskless a partir de ese snapshot.
Para SQL Server: antes de migrar, mueve los ficheros de tempdb de D:\ a un disco de datos Premium SSD adjunto, o a C:\ temporalmente. Usa ALTER DATABASE tempdb MODIFY FILE para redirigir las rutas. En Linux, deshabilita el swap en /dev/sdb antes del resize y reconfigura el swapfile en el disco OS o en un disco de datos después.
Controladora SCSI vs NVMe: la trampa invisible al migrar a v6 o v7
Las generaciones hasta Dv5/Ev5 utilizan SCSI como controladora de disco tanto para almacenamiento remoto como para el disco temporal local. A partir de Da/Ea/Fav6 y generaciones posteriores (incluida v7), NVMe es el modo soportado para el almacenamiento remoto. La documentación oficial de NVMe overview confirma esta distinción: «older generations (D/Ev5 or Fv2 and older) support SCSI; newer generations (Ebsv5, Da/Ea/Fav6 and newer) typically support only NVMe».
El cambio de controladora tiene consecuencias que van más allá de una diferencia de rendimiento: el sistema operativo invitado ve los discos de forma distinta. En Windows, los discos SCSI aparecen como \Device\Harddisk; en NVMe, la presentación cambia. Si el SO no tiene los drivers NVMe adecuados en el momento del arranque, la VM puede no iniciar. La documentación oficial establece que no se puede hacer un resize directo de una VM SCSI a una VM con NVMe remoto existe un workaround documentado en la FAQ de NVMe remoto (learn.microsoft.com/azure/virtual-machines/enable-nvme-remote-faqs). Además, las v6 y v7 requieren:
- Imagen Gen2 con tipo de seguridad Standard o Trusted Launch. Gen1 no soporta NVMe.
- Sistema operativo en la lista de imágenes soportadas. Para Windows: Windows Server 2019, 2022 y 2025, Windows 10 y Windows 11. Para Linux: RHEL 7.9+, Ubuntu 18.04+, SLES 15 SP4+, Debian 11+, Oracle Linux 7.9+, entre otros.
- MANA (Microsoft Azure Network Adapter): las VMs v6 y v7 lo requieren. El SO debe soportarlo. Para instalarlo antes del resize, consulta learn.microsoft.com/azure/virtual-network/accelerated-networking-mana-overview.
- Kernel de Linux con nvme_core.io_timeout configurado a 240 segundos (recomendación oficial para evitar que el OS-level timeout actúe antes que el mecanismo de Azure).
Si quieres habilitar NVMe en una VM existente sin cambiar de SKU (solo en SKUs que soportan ambas controladoras), puedes cambiar el diskControllerType con la VM deallocated:
# Azure CLI cambiar diskControllerType a NVMe (VM debe estar deallocated)
az vm deallocate –resource-group <rg> –name <vm-name>
az vm update \
–resource-group <rg> \
–name <vm-name> \
–set storageProfile.diskControllerType=NVMe
az vm start –resource-group <rg> –name <vm-name>
Importante: si la imagen del SO no está marcada como NVMe-compatible en Azure Compute Gallery o en Marketplace, la operación fallará con el error ‘The selected image is not supported for NVMe’. Verifica primero en learn.microsoft.com/azure/virtual-machines/enable-nvme-interface.
Licencias Windows al abandonar la B-series: coste de cómputo y AHB
La B-series tiene un modelo de precios que combina el coste del cómputo (relativamente bajo gracias al mecanismo de créditos de CPU) con la licencia de Windows Server incluida. Al migrar a D-series o E-series, el coste del cómputo base sube de forma significativa. Dicho de otro modo: el incremento en la factura mensual al pasar de una Standard_B4ms a una Standard_D4s_v5 no proviene principalmente de la licencia, sino del coste de cómputo del SKU base. La licencia Windows PAYG sube proporcionalmente, pero el salto mayor es el de la tasa de cómputo.
La diferencia puede ser especialmente visible en entornos con muchas VMs pequeñas de cargas intermitentes. Para calcular el impacto real, usa la Azure Pricing Calculator o la Retail Prices API especificando región, OS, tipo de instancia y modelo de facturación (PAYG, Reserved Instance o Savings Plan). Los precios varían por región, tipo de instancia y fecha de consulta, por lo que cualquier cifra publicada en un artículo queda obsoleta rápidamente.
La palanca principal para mitigar ese impacto es Azure Hybrid Benefit (AHB). Si tienes licencias de Windows Server con Software Assurance (SA) o suscripciones cualificadas, AHB te permite eliminar el componente de licencia Windows del precio de la VM y pagar solo la tasa de cómputo base. Algunos detalles operativos importantes de la documentación oficial:
- Requisito mínimo: 8 licencias de núcleo por VM (edición Datacenter o Standard), independientemente del tamaño de la VM. Incluso si ejecutas una VM de 4 vCPUs, necesitas al menos 8 licencias de núcleo para aplicar AHB.
- Para instancias con más de 8 cores, se requieren tantas licencias de núcleo como vCPUs tenga la VM (ejemplo: 12 licencias para una VM de 12 cores).
- AHB solo es válido durante el período activo del Software Assurance o la suscripción cualificada. Cuando expire, debes renovar, desactivar AHB o desaprovisionar las VMs beneficiadas.
- Cambiar el licenseType en una VM existente NO provoca reinicio ni interrumpe el servicio: solo modifica un flag de metadatos, según confirma la documentación oficial.
Para activar AHB en una VM existente:
# PowerShell — activar Azure Hybrid Benefit (AHB) en una VM existente
$vm = Get-AzVM -ResourceGroup «mi-rg» -Name «mi-vm»
$vm.LicenseType = «Windows_Server»
Update-AzVM -ResourceGroupName «mi-rg» -VM $vm
# Azure CLI — equivalente
az vm update \
–resource-group mi-rg \
–name mi-vm \
–set licenseType=Windows_Server
Verifica que el acuerdo de licenciamiento de tu organización incluye Windows Server con Software Assurance activo antes de activar AHB. Fuente: learn.microsoft.com/azure/virtual-machines/windows/hybrid-use-benefit-licensing
Azure-SSIS Integration Runtime y el retiro de la familia Dv2/Av2
Este punto afecta directamente a los clientes de Azure Data Factory (ADF) y Azure Synapse que utilizan Azure-SSIS IR (Integration Runtime para ejecutar paquetes SSIS). La documentación oficial lista los tamaños de nodo soportados para el IR, entre ellos SKUs de las familias ahora en proceso de retiro:
- Standard_D1_v2, Standard_D2_v2, Standard_D3_v2, Standard_D4_v2 — familia Dv2, retiro 01/05/2028
- Standard_A4_v2, Standard_A8_v2 — familia Av2/Amv2, retiro 15/11/2028
Microsoft advierte en la misma documentación que «los nodos v2 del Azure-SSIS IR no son adecuados para custom setup; si ya los usas, migra a nodos v3 lo antes posible». La recomendación actual es usar la familia Dv3 o Ev3 como mínimo. Si tu IR tiene nodos Standard_D8_v3 o superiores, ya estás en una posición más cómoda — aunque Dv3/Ev3 tampoco son eternos (actualmente activos pero sin RI renovable tras julio de 2026).
Cambiar el tamaño de nodo de un Azure-SSIS IR requiere detenerlo, modificar la configuración y volver a arrancarlo. No hay resize en caliente. El procedimiento es:
# PowerShell cambiar tamaño de nodo en Azure-SSIS IR (Stop -> Set -> Start)
$DataFactoryName = «mi-adf»
$ResourceGroupName = «mi-rg»
$IntegrationRuntimeName = «mi-ssis-ir»
# 1. Detener el IR
Stop-AzDataFactoryV2IntegrationRuntime `
-DataFactoryName $DataFactoryName `
-ResourceGroupName $ResourceGroupName `
-Name $IntegrationRuntimeName
# 2. Actualizar tamaño de nodo (p.ej. de Standard_D4_v2 a Standard_D8_v3)
Set-AzDataFactoryV2IntegrationRuntime `
-DataFactoryName $DataFactoryName `
-ResourceGroupName $ResourceGroupName `
-Name $IntegrationRuntimeName `
-NodeSize Standard_D8_v3
# 3. Arrancar el IR
Start-AzDataFactoryV2IntegrationRuntime `
-DataFactoryName $DataFactoryName `
-ResourceGroupName $ResourceGroupName `
-Name $IntegrationRuntimeName
En cuanto a la Self-hosted IR: este tipo de IR corre en VMs IaaS gestionadas por el cliente, no por el servicio ADF. Si esas VMs usan series en proceso de retiro, son VMs ordinarias que hay que redimensionar siguiendo el procedimiento estándar. No hay ninguna configuración especial del IR que requiera actualizarse por el cambio de SKU, siempre que el SO y los drivers sean compatibles.
PARTE 2 Runbook operable de producción
Todo lo que sigue está diseñado para ser entregado directamente a operaciones, L1 y L2. No es un resumen del artículo anterior: es el procedimiento ejecutable, con las comprobaciones que bloquean la ejecución y los comandos exactos a lanzar en cada fase. Rellena la ficha por VM antes de abrir cualquier ventana de mantenimiento. Las abreviaturas que aparecen en este runbook: PPG = Proximity Placement Group (grupo de colocación por proximidad), AHB = Azure Hybrid Benefit, AMA = Azure Monitor Agent, AS = Availability Set (conjunto de disponibilidad), VMSS = Virtual Machine Scale Set (conjunto de escalado de máquinas virtuales), RI = Reserved Instance (instancia reservada), MANA = Microsoft Azure Network Adapter.
Árbol de decisión: ¿qué tipo de resize tengo?
Antes de ejecutar un solo comando, determina en cuál de estos casos estás. Cada caso tiene un camino distinto algunos permiten resize directo, otros requieren un workaround documentado por Microsoft, y algunos no se resuelven con resize en absoluto.
¿Cuál es mi situación?
│
├─ VM individual (no en VMSS, no en AKS, no en AVD)
│ │
│ ├─ SKU origen y SKU destino con el mismo tipo de controladora (SCSI→SCSI o NVMe→NVMe)
│ │ ├─ Mismo estado de disco temporal (con disco→con disco, o sin→sin)
│ │ │ └─ ► RESIZE DIRECTO: deallocate → resize → start
│ │ └─ Distinto estado disco temporal (Windows: con→sin o sin→con)
│ │ └─ ► WORKAROUND: mover pagefile.sys → snapshot → nueva VM
│ │
│ └─ SKU destino es NVMe (v6, v7, Ebsv5) y origen es SCSI
│ ├─ OS es Gen1
│ │ └─ ► NO RESIZE: necesitas nueva VM Gen2
│ └─ OS es Gen2 con imagen NVMe-compatible
│ └─ ► WORKAROUND NVMe: script azure-nvme-VM-update.ps1
│
├─ VM en Availability Set (AS)
│ ├─ AS NO anclado a clúster específico
│ │ └─ ► Detener TODAS las VMs del AS → resize → reiniciar
│ └─ AS anclado a clúster (ej: Azure NetApp Files M-series)
│ └─ ► TICKET DE SOPORTE: Microsoft gestiona manualmente
│
├─ VM en PPG (Proximity Placement Group) sin AS
│ └─ ► Detener todas las VMs del PPG → resize → reiniciar el resto
│
├─ VMSS (Virtual Machine Scale Set)
│ └─ ► Ver sección Mini-runbook VMSS más abajo
│
├─ AKS node pool
│ └─ ► Crear nuevo node pool con SKU destino (az aks nodepool add) → kubectl cordon de los nodos del pool antiguo → kubectl drain –ignore-daemonsets –delete-emptydir-data → validar pods (kubectl get pods -o wide -A) → az aks nodepool delete del pool antiguo
│ Fuente: learn.microsoft.com/azure/aks/resize-node-pool
│
├─ AVD host pool
│ └─ ► Actualizar el pool con nuevos session hosts → drenar y eliminar los antiguos
│
├─ Azure Batch pool
│ └─ ► Crear nuevo pool con SKU destino → reasignar jobs → eliminar el antiguo
│
└─ FPGA (NP-series) / GPU con cambio de vendor
└─ ► NO RESIZE: migración de aplicación (FPGA→GPU o GPU distinto)
AVISO: Este árbol de decisión es el primer punto de entrada. Si el operador no puede identificar claramente su caso antes de ejecutar, debe escalar a L2 o arquitectura antes de continuar.
Ficha de ejecución por VM (rellenar antes de operar)
Sin esta ficha completada y revisada, no se ejecuta ningún paso del runbook. Su propósito es doble: forzar que el operador haya verificado todos los prerequisitos antes de abrir la ventana de mantenimiento, y documentar el estado previo para poder ejecutar el rollback con información completa. Copia este bloque en el ticket de cambio o en el sistema de ITSM de tu organización. Todos los campos son obligatorios; si un campo no aplica, escribe «N/A» con una justificación.
============================================================
FICHA DE EJECUCIÓN — RESIZE DE VM EN AZURE
Completar ANTES de iniciar la ventana de mantenimiento
============================================================
Subscription: [ID o nombre de la suscripción]
Resource Group: [Nombre exacto del resource group]
VM name: [Nombre de la VM tal como aparece en Azure]
Region / Zone: [Ej: westeurope / Zone 1]
Current SKU: [Ej: Standard_D4_v2]
Target SKU: [Ej: Standard_D4s_v5]
— Sistema operativo y generación —
OS (Windows/Linux + versión): [Ej: Windows Server 2022]
Generation (Gen1/Gen2): [Ej: Gen2]
Security type: [Standard / TrustedLaunch / Confidential]
Current disk controller: [SCSI / NVMe — verificar con az vm show]
Target disk controller: [SCSI / NVMe — según la familia destino]
— Disco temporal —
Has local temp disk (Yes/No): [Consultar la página de specs del SKU]
Uses D:\ or /mnt/resource (Yes/No): [Verificar dentro del SO]
SQL Server tempdb on temp disk: [Yes/No — consultar sys.master_files]
Pagefile/swap location: [Ej: C:\ pagefile.sys / /dev/sda2]
— Alta disponibilidad —
Availability Set: [Nombre del AS o «Ninguno»]
Proximity Placement Group: [Nombre del PPG o «Ninguno»]
— Backup y rollback —
Backup/snapshot completed (timestamp + ID):
OS disk snapshot ID:
Data disk 1 snapshot ID:
[añadir una línea por cada disco de datos]
Maintenance window: [Ej: 2026-06-10 02:00–04:00 UTC]
Rollback SKU: [SKU original, en caso de rollback]
— Responsables —
Application owner: [Nombre y contacto]
Validation owner: [Quién valida post-resize]
Change ticket / approval: [Referencia del sistema ITSM]
============================================================
Stop conditions: condiciones que bloquean la ejecución
Si alguna de las siguientes condiciones se cumple, la operación no debe ejecutarse. Cada condición tiene respaldo en documentación oficial de Microsoft Learn. Resolver el bloqueo antes de continuar. El operador L1 evalúa cada condición como «sí/no» si hay alguna duda, escalar a L2 antes de continuar.
STOP Condiciones que bloquean el resize:
[ ] Target SKU es NVMe-only y la VM es Gen1
→ Gen1 no soporta NVMe. Requiere nueva VM Gen2 (no es resize, es recreación).
Cómo verificar: az vm get-instance-view \
–resource-group <mi-rg> \
–name <mi-vm> \
–query «hyperVGeneration» \
–output tsv
(Devuelve «V1» o «V2». La propiedad hyperVGeneration está documentada en el
instance view de la REST API de Compute: learn.microsoft.com/rest/api/compute/
virtual-machines/instance-view)
Fuente: learn.microsoft.com/azure/virtual-machines/nvme-overview
[ ] Windows VM: movimiento entre tamaños con disco temporal y sin disco temporal (o viceversa)
→ No existe resize directo en Windows para este caso. Usar workaround oficial (snapshot + nueva VM).
Cómo verificar: consultar specs del SKU origen y destino — si uno tiene «d» y el otro no, es cruce.
Fuente: learn.microsoft.com/azure/virtual-machines/azure-vms-no-temp-disk
learn.microsoft.com/azure/virtual-machines/sizes/resize-vm
[ ] Pagefile / SQL tempdb / swap está todavía en el disco temporal
→ Mover primero a disco OS o disco de datos, luego proceder.
Cómo verificar (Windows): Get-CimInstance Win32_PageFileSetting
Cómo verificar (SQL): SELECT physical_name FROM sys.master_files WHERE database_id = 2
Cómo verificar (Linux): swapon –show
[ ] SCSI → NVMe remoto (target es v6, v7 o Ebsv5)
→ No existe resize directo. Usar workaround NVMe documentado
(script azure-nvme-VM-update.ps1 o procedimiento equivalente).
Fuente: learn.microsoft.com/azure/virtual-machines/enable-nvme-remote-faqs
[ ] Imagen del SO no es NVMe-compatible (cuando el target requiere NVMe)
→ Verificar lista oficial antes de proceder.
Fuente: learn.microsoft.com/azure/virtual-machines/enable-nvme-interface
[ ] Driver MANA no instalado en el SO (para targets v6/v7 que lo requieren)
→ Instalar MANA antes de proceder.
Cómo verificar (Windows): Get-NetAdapter | Where-Object {$_.InterfaceDescription -like «*MANA*»}
Cómo verificar (Linux): lsmod | grep mana
Fuente: learn.microsoft.com/azure/virtual-network/accelerated-networking-mana-overview
[ ] Target SKU no disponible en la región/zona objetivo
→ Verificar con:
az vm list-skus –location <region> –size <prefijo> –zone <número> –output table
Cómo interpretarlo: si la columna Restrictions muestra NotAvailableForSubscription, el SKU no está disponible para esa suscripción/región/zona puede deberse a restricciones de disponibilidad, tipo de suscripción, región o capacidad. La cuota se verifica aparte con «Usage + quotas» en el portal o con az vm list-usage –location <region> –output table. Ten en cuenta que las cuotas de Compute tienen dos niveles: (1) vCPU regional total, que limita el número de vCPUs de cualquier familia en la región; y (2) vCPU por familia de tamaño (Dsv5, Esv5, Dasv6, etc.), que aplica de forma independiente por serie.
[ ] Cuota vCPU insuficiente para la familia objetivo
→ Solicitar aumento en portal.azure.com > Suscripción > Uso y cuotas.
Cómo verificar: az vm list-usage –location <region> –output table | grep -i <familia>
[ ] VM en Availability Set y otras VMs del set no pueden detenerse en la misma ventana
→ Coordinar ventana de mantenimiento con todos los propietarios del AS.
[ ] VM en PPG y el target SKU no está soportado en ese PPG
→ Verificar disponibilidad en el PPG antes de proceder.
[ ] El propietario de la aplicación NO ha aprobado el plan de validación
→ Obtener aprobación explícita (email o ticket) antes de abrir la ventana de mantenimiento.
[ ] No se ha tomado snapshot en las últimas X horas (según política de tu organización)
→ Tomar snapshot antes de continuar. Es el único rollback inmediato disponible.
ADVERTENCIA: para workloads transaccionales (SQL Server, Oracle, SAP, controladores de dominio),
un snapshot de disco puede no ser suficiente como backup application-consistent.
Un snapshot de disco sin coordinación con VSS (Windows) o pre/post scripts (Linux) es crash-consistent:
captura el estado del disco en un instante, pero no garantiza coherencia de transacciones en vuelo.
Para estos workloads, valida Azure Backup con restore point application-consistent,
backup nativo de la base de datos, o procedimiento de quiesce antes del snapshot.
Microsoft distingue tres niveles de consistencia documentados en
learn.microsoft.com/azure/backup/backup-azure-vms-introduction:
· Application-consistent: coordina con VSS writers (Windows) o pre/post scripts (Linux)
garantiza arranque sin pérdida de datos ni corrupción de transacciones.
· File-system consistent: snapshot de todos los archivos al mismo tiempo
el SO arranca pero las apps pueden necesitar recuperación propia.
· Crash-consistent: solo captura datos en disco equivale a un corte de luz;
las aplicaciones transaccionales pueden quedar en estado inconsistente.
[ ] El restore desde backup no se ha testado recientemente
→ Validar que el restore funciona antes del cambio en producción.
Guía operativa paso a paso para el resize
Este es el procedimiento genérico y reutilizable. Adapta los pasos opcionales según si cambias de controladora (SCSI → NVMe), de modelo de disco temporal (con → sin) o si la VM está en un Availability Set. Cada fase tiene numeración propia, reiniciada desde 1. Los placeholders entre < > deben sustituirse por los valores reales de tu entorno antes de ejecutar.
Fase 1 Pre-checks e inventario completo antes de tocar nada
1. Completar la ficha de ejecución por VM (ver sección anterior). Sin ficha completada, no se avanza.
2. Snapshot del disco OS y todos los discos de datos adjuntos. Es tu rollback inmediato. Documenta el ID de cada snapshot en la ficha. AVISO de consistencia: si la VM ejecuta SQL Server, Oracle, SAP o actúa como controlador de dominio, un snapshot ad-hoc es crash-consistent por defecto revisa la stop condition de backup antes de proceder. Fuente sobre niveles de consistencia: learn.microsoft.com/azure/backup/backup-azure-vms-introduction
3. Inventario completo de recursos afectados. No solo las VMs sueltas también:
- VMSS (Microsoft.Compute/virtualMachineScaleSets) escalan automáticamente y pueden estar usando SKUs retirados.
- AVD (Azure Virtual Desktop) host pools — sus session hosts pueden estar en B-series o Dv2.
- AKS node pools los node pools de versiones antiguas pueden referenciar SKUs en retiro.
- Azure Batch pools configurados con tamaños de VM específicos que hay que actualizar antes del retiro.
- Imágenes custom en Azure Compute Gallery si tienen SKUs de series retiradas codificados en la definición de imagen.
Para identificar todos los recursos afectados, usa Azure Resource Graph. A continuación dos versiones de la query, seguidas de una query dedicada para VMSS:
Version 1 Amplia (punto de partida; puede incluir SKUs actuales con prefijo similar):
// Azure Resource Graph VMs con SKUs potencialmente en retiro
// AVISO: esta query es un punto de partida. Valida el resultado contra
// learn.microsoft.com/azure/virtual-machines/sizes/retirement/retired-sizes-list
// antes de actuar. No uses esta lista como fuente de verdad sin revisión manual.
resources
| where type =~ ‘microsoft.compute/virtualmachines’
| extend vmSize = tostring(properties.hardwareProfile.vmSize)
| where vmSize has_any (
‘Standard_D1’, ‘Standard_D2’, ‘Standard_D3’, ‘Standard_D4’,
‘Standard_D11’, ‘Standard_D12’, ‘Standard_D13’, ‘Standard_D14’,
‘Standard_DS1’, ‘Standard_DS2’, ‘Standard_DS3’, ‘Standard_DS4’,
‘Standard_DS11’, ‘Standard_DS12’, ‘Standard_DS13’, ‘Standard_DS14’,
‘Standard_D1_v2’, ‘Standard_D2_v2’, ‘Standard_D3_v2’, ‘Standard_D4_v2’,
‘Standard_A4_v2’, ‘Standard_A8_v2’,
‘Standard_B1ls’, ‘Standard_B1s’, ‘Standard_B1ms’,
‘Standard_B2s’, ‘Standard_B2ms’, ‘Standard_B4ms’, ‘Standard_B8ms’,
‘Standard_B12ms’, ‘Standard_B16ms’, ‘Standard_B20ms’,
‘Standard_F1’, ‘Standard_F2’, ‘Standard_F4’, ‘Standard_F8’,
‘Standard_Fs’, ‘Standard_G’, ‘Standard_GS’,
‘Standard_L4s’, ‘Standard_L8s’, ‘Standard_L16s’, ‘Standard_L32s’,
‘Standard_NV’, ‘Standard_NP’,
‘Standard_HB120rs_v2’, ‘Standard_HC44’
)
| project subscriptionId, resourceGroup, name, location, vmSize
| order by vmSize asc
Version 2 — Estricta por familia con regex (menos falsos positivos, más precisa):
// Azure Resource Graph query estricta por familia retirada con regex
// Usa ‘matches regex’ para cada familia exacta.
// Familias verificadas contra learn.microsoft.com/azure/virtual-machines/sizes/
// NOTA: valida siempre el resultado contra la lista oficial antes de actuar.
resources
| where type =~ ‘microsoft.compute/virtualmachines’
| extend vmSize = tostring(properties.hardwareProfile.vmSize)
| where
// D v1 (compute): Standard_D1 a D4
vmSize matches regex @’^Standard_D[1-4]$’
// D v1 (memory): Standard_D11 a D14
or vmSize matches regex @’^Standard_D1[1-4]$’
// DS v1 (compute): Standard_DS1 a DS4
or vmSize matches regex @’^Standard_DS[1-4]$’
// DS v1 (memory): Standard_DS11 a DS14
or vmSize matches regex @’^Standard_DS1[1-4]$’
// Dv2: Standard_D1_v2 a D5_v2
or vmSize matches regex @’^Standard_D[1-5]_v2$’
// Dsv2: Standard_DS1_v2 a DS5_v2
or vmSize matches regex @’^Standard_DS[1-5]_v2$’
// Av2: Standard_A1_v2 a A8_v2
or vmSize matches regex @’^Standard_A[1-8]_v2$’
// Amv2: Standard_A2m_v2, A4m_v2, A8m_v2
or vmSize matches regex @’^Standard_A[248]m_v2$’
// B-series V1 — todos los SKUs documentados en learn.microsoft.com/azure/virtual-machines/sizes/general-purpose/bv1-series
// Incluye B1ls2 (solo Linux), B1ls (variante), B1s, B1ms, B2s, B2ms, B4ms, B8ms, B12ms, B16ms, B20ms
or vmSize matches regex @’^Standard_B(1ls2?|1s|1ms|2s|2ms|4ms|8ms|12ms|16ms|20ms)$’
// F-series v1 (compute): Standard_F1 a F72
or vmSize matches regex @’^Standard_F[0-9]+$’
// Fs-series v1: Standard_F1s a F72s
or vmSize matches regex @’^Standard_F[0-9]+s$’
// Fsv2: Standard_F2s_v2 a F72s_v2
or vmSize matches regex @’^Standard_F[0-9]+s_v2$’
// G-series: Standard_G1 a G5
or vmSize matches regex @’^Standard_G[1-5]$’
// GS-series: Standard_GS1 a GS5
or vmSize matches regex @’^Standard_GS[1-5]$’
// Ls v1 (Lsv1): Standard_L4s, L8s, L16s, L32s
or vmSize matches regex @’^Standard_L(4|8|16|32)s$’
// Lsv2: Standard_L8s_v2 a L80s_v2
or vmSize matches regex @’^Standard_L[0-9]+s_v2$’
// HBv2: Standard_HB120rs_v2 y variantes con vCPUs restringidas
or vmSize =~ ‘Standard_HB120rs_v2′
or vmSize matches regex @’^Standard_HB120-[0-9]+rs_v2$’
// HC: Standard_HC44rs, HC44-16rs, HC44-32rs
or vmSize matches regex @’^Standard_HC44(-[0-9]+)?rs$’
// NVv3: Standard_NV12s_v3, NV24s_v3, NV48s_v3
or vmSize matches regex @’^Standard_NV[0-9]+s_v3$’
// NVv4: Standard_NV4as_v4 a NV64as_v4
or vmSize matches regex @’^Standard_NV[0-9]+as_v4$’
// NP-series: Standard_NP10s, NP20s, NP40s
or vmSize matches regex @’^Standard_NP[0-9]+s$’
// M192 v2 — los 4 SKUs confirmados en retired-sizes-list
or vmSize matches regex @’^Standard_M192i(d)?ms_v2$’
or vmSize matches regex @’^Standard_M192i(d)?s_v2$’
| project subscriptionId, resourceGroup, name, location, vmSize
| order by vmSize asc
Para VMSS, usa la misma lógica con el tipo correcto:
// Azure Resource Graph VMSS con SKUs potencialmente retirados (versión estricta)
resources
| where type =~ ‘microsoft.compute/virtualmachinescalesets’
| extend vmSize = tostring(properties.virtualMachineProfile.hardwareProfile.vmSize)
| where
vmSize matches regex @’^Standard_D[1-4]$’
or vmSize matches regex @’^Standard_D1[1-4]$’
or vmSize matches regex @’^Standard_DS[1-4]$’
or vmSize matches regex @’^Standard_DS1[1-4]$’
or vmSize matches regex @’^Standard_D[1-5]_v2$’
or vmSize matches regex @’^Standard_DS[1-5]_v2$’
or vmSize matches regex @’^Standard_A[1-8]_v2$’
or vmSize matches regex @’^Standard_B(1ls2?|1s|1ms|2s|2ms|4ms|8ms|12ms|16ms|20ms)$’
or vmSize matches regex @’^Standard_F[0-9]+s?$’
or vmSize matches regex @’^Standard_F[0-9]+s_v2$’
or vmSize =~ ‘Standard_HB120rs_v2′
or vmSize matches regex @’^Standard_HB120-[0-9]+rs_v2$’
or vmSize matches regex @’^Standard_HC44(-[0-9]+)?rs$’
or vmSize matches regex @’^Standard_NV[0-9]+s_v3$’
or vmSize matches regex @’^Standard_NV[0-9]+as_v4$’
or vmSize matches regex @’^Standard_NP[0-9]+s$’
| project subscriptionId, resourceGroup, name, location, vmSize, sku = tostring(sku.name)
Nota: Ambas versiones de las queries son herramientas de inventario, no fuentes de verdad. Valida siempre el resultado contra la lista oficial: learn.microsoft.com/azure/virtual-machines/sizes/retirement/retired-sizes-list. Los SKUs de D/DS v1 (Standard_D1 a D4 y D11 a D14, Standard_DS1 a DS4 y DS11 a DS14) están documentados en learn.microsoft.com/azure/virtual-machines/sizes/previous-gen-sizes-list. Los SKUs de Dv2/Dsv2 son exclusivamente D1_v2–D5_v2 y DS1_v2–DS5_v2 — no existe D11_v2 ni DS11_v2 en esta familia. Los SKUs de B-series V1 están documentados en learn.microsoft.com/azure/virtual-machines/sizes/general-purpose/bv1-series.
4. Verificar cuota suficiente para el SKU destino:
# Verificar SKUs disponibles en una región y zona concreta
# Sustituye <region> por tu región (ej: westeurope) y <prefijo> por la familia objetivo (ej: Standard_D)
az vm list-skus \
–location <region> \
–size <prefijo> \
–zone 1 \
–output table
# Ver los tamaños que admite la VM actual en su cluster actual (tras deallocate, aparecen más opciones)
az vm list-vm-resize-options \
–resource-group <mi-rg> \
–name <mi-vm> \
–output table
5. Confirmar si la VM está en Availability Set (AS) o PPG si está, leer la sección del árbol de decisión correspondiente antes de continuar. Un AS o PPG puede requerir detener otras VMs del grupo.
6. Verificar compatibilidad de disco temporal: ¿va de VM con disco a VM sin disco en Windows? Si es así, mover primero el pagefile.sys siguiendo la guía oficial antes de continuar.
7. Verificar si el SKU destino es NVMe-only (v6, v7 o Ebsv5): comprobar que el SO actual es Gen2 y está en la lista de imágenes soportadas. Comprobar también que MANA está instalado.
8. Revisar RIs activas: si tienes reservas en las series afectadas, gestionar el canje o conversión a Azure Savings Plan antes del resize para no perder valor.
Fase 2 Ejecutar el resize
Opción A Azure CLI (recomendado para automatización):
# Variables sustituir por los valores reales antes de ejecutar
RESOURCE_GROUP=»<mi-rg>»
VM_NAME=»<mi-vm>»
TARGET_SIZE=»<Standard_D4s_v5>»
# 1. Detener (deallocate) la VM
az vm deallocate –resource-group $RESOURCE_GROUP –name $VM_NAME
# 2. Verificar que el tamaño está disponible tras deallocate
# Si no aparece en el listado, la región/zona no tiene capacidad
az vm list-vm-resize-options \
–resource-group $RESOURCE_GROUP \
–name $VM_NAME \
–query «[?name==’$TARGET_SIZE’]» \
–output table
# 3. Resize
az vm resize \
–resource-group $RESOURCE_GROUP \
–name $VM_NAME \
–size $TARGET_SIZE
# 4. Arrancar
az vm start –resource-group $RESOURCE_GROUP –name $VM_NAME
Opción B — PowerShell:
# Variables sustituir por los valores reales antes de ejecutar
$resourceGroup = «<mi-rg>»
$vmName = «<mi-vm>»
$targetSize = «<Standard_D4s_v5>»
# 1. Obtener el objeto VM
$vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
# 2. Detener (deallocate)
Stop-AzVM -ResourceGroupName $resourceGroup -Name $vmName -Force
# 3. Verificar disponibilidad del tamaño
$available = Get-AzVMSize -ResourceGroupName $resourceGroup -VMName $vmName |
Where-Object { $_.Name -eq $targetSize }
if (-not $available) {
Write-Warning «El tamaño $targetSize no está disponible en este cluster. Verificar capacidad.»
exit 1
}
# 4. Resize
$vm.HardwareProfile.VmSize = $targetSize
Update-AzVM -ResourceGroupName $resourceGroup -VM $vm
# 5. Arrancar
Start-AzVM -ResourceGroupName $resourceGroup -Name $vmName
Si el tamaño destino no aparece en la lista de resize-options aunque la VM esté deallocated, puede deberse a que la región o zona no tiene capacidad disponible para ese SKU. Usa «az vm list-skus –location <region> –size <prefijo> –output table» para verificar disponibilidad y restricciones de zona.
Fase 3 Validación post-resize (Azure-side + guest-side)
La validación tiene dos niveles: verificación desde el plano de control de Azure y verificación dentro del sistema operativo invitado. Ambos son necesarios — el plano de control puede mostrar el tamaño correcto aunque la VM siga en el SKU anterior si el resize falló sin reporte de error (comportamiento documentado por Microsoft en learn.microsoft.com/azure/virtual-machines/sizes/resize-vm).
Validación Azure-side:
1. Confirmar que el tamaño activo es el esperado:
# Azure CLI — mostrar el SKU actual de la VM
az vm show \
–resource-group <mi-rg> \
–name <mi-vm> \
–query «hardwareProfile.vmSize» \
–output tsv
# PowerShell — equivalente
(Get-AzVM -ResourceGroupName «<mi-rg>» -Name «<mi-vm>»).HardwareProfile.VmSize
AVISO: Si una operación de resize falla, el modelo de la VM mostrará igualmente el tamaño solicitado aunque la VM siga ejecutándose en el tamaño anterior. Este comportamiento afecta tanto al portal como a todas las operaciones GET. No basta con comprobar el tamaño en el modelo: hay que validar también que la VM arrancó correctamente y que las métricas del SO confirman el nuevo SKU. Fuente: learn.microsoft.com/azure/virtual-machines/sizes/resize-vm
2. Verificar que el sistema operativo ha arrancado correctamente: revisar Boot Diagnostics en el portal o con «az vm boot-diagnostics get-boot-log –resource-group <mi-rg> –name <mi-vm>».
3. Comprobar conectividad de red y que la aplicación responde.
4. Si se cambió a NVMe: verificar que los discos se ven correctamente desde el SO y que las rutas de aplicación no han cambiado.
5. Si se eliminó el disco temporal: verificar que el pagefile.sys está en C: y que SQL Server tempdb apunta a la ruta correcta.
6. Revisar métricas en Azure Monitor durante al menos 15 minutos para detectar anomalías — y comparar con las métricas basales del SKU anterior si las tienes guardadas.
Validación guest-side — Windows (PowerShell, ejecutar dentro del SO):
# Verificar CPU y memoria que ve el SO (deben coincidir con el SKU destino)
Get-ComputerInfo | Select-Object CsNumberOfLogicalProcessors, CsTotalPhysicalMemory
# Verificar discos físicos y controladora
Get-Disk
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, BusType, Size
# Verificar modelo y LUN de discos (NVMe aparece como ‘Virtual_Disk NVMe Premium’)
wmic diskdrive get model,scsilogicalunit
# Verificar ubicación del pagefile (debe estar en C: si migraste a diskless)
Get-CimInstance Win32_PageFileSetting
# Verificar que los servicios del agente Azure están corriendo
Get-Service vmictimesync, vmickvpexchange, WindowsAzureGuestAgent
Validación guest-side Linux (bash, ejecutar dentro del SO):
# Verificar CPU y memoria que ve el SO
lscpu
free -h
# Verificar discos, tipo y puntos de montaje
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL
# Verificar estado del swap
swapon –show
# Verificar NVMe (requiere nvme-cli instalado; falla silenciosamente si no hay NVMe)
# Instalar si no está: apt install nvme-cli / yum install nvme-cli
sudo nvme list || echo «nvme-cli no instalado o no hay discos NVMe»
# Verificar espacio en filesystems
df -h
# Verificar mensajes NVMe en el kernel (útil para troubleshooting de arranque)
dmesg | grep -i nvme | head -20
# Verificar que el agente Azure Linux (WaLinuxAgent) está activo
# Aparece como ‘walinuxagent’ en Ubuntu/Debian o ‘waagent’ en RHEL/CentOS
systemctl status walinuxagent 2>/dev/null || systemctl status waagent
Nota: nvme list requiere el paquete nvme-cli instalado en el sistema operativo. El agente Azure puede aparecer como «walinuxagent» o «waagent» según la distribución. Los comandos de validación guest-side deben ejecutarse con la sesión ya establecida en la VM (RDP o SSH) después de que la VM haya arrancado completamente.
Fase 4 Plan de rollback completo
Si algo falla tras el resize, el rollback más rápido es volver al SKU original. Dado que la VM fue deallocated antes del resize, el cluster puede haber cambiado y puede que el SKU original ya no esté disponible en ese cluster. Si eso ocurre, usa el snapshot tomado en la fase de pre-checks para recrear la VM desde cero en el SKU original.
# PASO 1 Crear un disco a partir del snapshot de rollback
# Sustituir <snapshot-id> por el ID documentado en la ficha de ejecución
az disk create \
–resource-group <mi-rg> \
–name <mi-vm-os-rollback> \
–source <snapshot-id>
# PASO 2 — Crear VM desde ese disco (ajusta –size al SKU original de la ficha)
# Sustituir <mi-rg>, <mi-vm-rollback>, <mi-vm-os-rollback>, <SKU-original>
az vm create \
–resource-group <mi-rg> \
–name <mi-vm-rollback> \
–attach-os-disk <mi-vm-os-rollback> \
–os-type Windows \
–size <Standard_D2s_v3>
AVISO: Crear una VM nueva desde snapshot recupera el SO y los datos, pero puede romper identidad, conectividad y dependencias de aplicación si no se documenta el estado previo. Antes de ejecutar el rollback, verifica que tienes documentados en la ficha todos los elementos de la VM original:
Rollback debe preservar (verificar antes de recrear la VM):
— Red y conectividad —
[ ] NIC original (mismo objeto si es posible; reutilízala con –nics <nic-id>)
[ ] Private IP (estática o reservada — documenta el valor antes del resize)
[ ] Public IP, si la había (misma IP pública asociada a la NIC)
[ ] NSG associations a nivel de NIC y subnet
[ ] DNS records si la aplicación depende del hostname
— Identidad y acceso —
[ ] Managed identity system-assigned (se regenera con nueva VM; actualizar en todos los RBAC donde aparezca)
[ ] Managed identity user-assigned (re-asociar a la nueva VM)
[ ] Tags (copiar de la VM original)
[ ] Domain join (hostname + SID + FQDN — si cambia el nombre de VM, el dominio se pierde y hay que re-unir)
— Alta disponibilidad —
[ ] Availability Set (no se puede mover entre AS; la nueva VM debe crearse en el mismo AS)
[ ] Zone (la nueva VM debe crearse en la misma zona de disponibilidad)
[ ] Proximity Placement Group
— Almacenamiento —
[ ] Data disk LUN order (mismo LUN en mismo orden al adjuntar los discos de datos)
[ ] Backup policy (re-attach al vault de Recovery Services)
— Monitorización y seguridad —
[ ] Monitoring extensions (AMA / Log Analytics / Dependency Agent) — re-instalar tras recreación
[ ] Antimalware / security extensions
[ ] Diagnostic settings y boot diagnostics storage account
[ ] Auto-shutdown policies
Nota: La lista de elementos de rollback no está completamente documentada como procedimiento oficial en learn.microsoft.com Microsoft documenta el proceso técnico de recrear la VM desde snapshot, pero los ítems de identidad, extensiones y dominio son responsabilidad del equipo de operaciones. Este runbook los recoge como checklist operativo basado en la estructura de recursos de Azure IaaS.
Mini-runbook VM Scale Sets (VMSS)
Un VMSS no se redimensiona de la misma forma que una VM individual. El proceso consiste en actualizar el modelo del VMSS y luego propagar el cambio a las instancias según la política de actualización (upgradePolicy) configurada: Manual, Automatic o Rolling. Este mini-runbook cubre el flujo completo.
1. Confirmar el orchestration mode del VMSS: Uniform o Flexible. El modo determina qué APIs se usan para gestionar las instancias. Flexible es el modo recomendado para nuevos despliegues (permite gestión con APIs estándar de VM); Uniform es el modo legacy (requiere APIs específicas de VMSS). No se puede cambiar el modo de orquestación después de la creación.
# Azure CLI consultar orchestration mode y upgradePolicy del VMSS
# Sustituir <mi-rg> y <mi-vmss> por los valores reales
az vmss show \
–resource-group <mi-rg> \
–name <mi-vmss> \
–query «{orchestrationMode:orchestrationMode, upgradePolicy:upgradePolicy.mode, currentSku:sku.name}» \
–output table
2. Revisar la upgradePolicy actual: Manual, Automatic o Rolling. Esta política determina si las instancias existentes se actualizarán automáticamente o si el operador debe iniciar la actualización manualmente. En producción, Manual o Rolling son las políticas más comunes para garantizar disponibilidad.
3. Actualizar el modelo del VMSS con el nuevo SKU destino. Esta operación solo actualiza el modelo las instancias existentes NO cambian todavía hasta que se aplique la actualización (paso siguiente).
# Azure CLI actualizar el SKU en el modelo del VMSS
# Sustituir <mi-rg>, <mi-vmss> y <Standard_D4s_v5> por los valores reales
az vmss update \
–resource-group <mi-rg> \
–name <mi-vmss> \
–set sku.name=<Standard_D4s_v5>
# PowerShell equivalente
$vmss = Get-AzVmss -ResourceGroupName «<mi-rg>» -VMScaleSetName «<mi-vmss>»
$vmss.Sku.Name = «<Standard_D4s_v5>»
Update-AzVmss -ResourceGroupName «<mi-rg>» -Name «<mi-vmss>» -VirtualMachineScaleSet $vmss
4. Verificar que el modelo muestra el nuevo SKU antes de propagar a instancias:
az vmss show \
–resource-group <mi-rg> \
–name <mi-vmss> \
–query «sku.name» \
–output tsv
5. Propagar el cambio a las instancias según la upgradePolicy. Elige el método que corresponda a tu política:
Si upgradePolicy es Manual actualizar instancias de forma controlada:
# Ver qué instancias tienen el modelo desactualizado (latestModelApplied = false)
az vmss list-instances \
–resource-group <mi-rg> \
–name <mi-vmss> \
–query «[?latestModelApplied==\`false\`].{id:instanceId, name:name, latestModel:latestModelApplied}» \
–output table
# Actualizar instancias específicas (sustituir 0 1 2 por los IDs reales)
az vmss update-instances \
–resource-group <mi-rg> \
–name <mi-vmss> \
–instance-ids 0 1 2
# O actualizar todas las instancias de una vez (con impacto de disponibilidad)
az vmss update-instances \
–resource-group <mi-rg> \
–name <mi-vmss> \
–instance-ids ‘*’
Si upgradePolicy es Rolling — el VMSS actualiza en batches preservando disponibilidad:
# Iniciar rolling upgrade (solo disponible en Uniform orchestration con health probe o App Health Extension)
# El rolling upgrade actualiza instancias en batches; respeta el maxUnhealthyPercentage configurado
az vmss rolling-upgrade start \
–resource-group <mi-rg> \
–name <mi-vmss>
# Ver el estado del rolling upgrade en curso
az vmss rolling-upgrade get-latest \
–resource-group <mi-rg> \
–name <mi-vmss>
Nota: Rolling upgrade en Flexible Orchestration requiere la Application Health Extension instalada en las instancias. En Uniform Orchestration puede usarse también un health probe de Load Balancer. Fuente: learn.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-policy
Si upgradePolicy es Automatic Azure aplica el cambio sin intervención manual (solo DevTest):
# Con Automatic, el cambio de SKU en el modelo (paso 3) ya inicia la actualización.
# Monitorear el progreso con:
az vmss get-instance-view \
–resource-group <mi-rg> \
–name <mi-vmss> \
–query «virtualMachine.statusesSummary» \
–output table
6. Validar instancias una a una después de la actualización. Usa los mismos comandos guest-side de la Fase 3 del runbook principal. Puedes conectarte a instancias individuales con:
# Ver IDs y estado de todas las instancias del VMSS
az vmss list-instances \
–resource-group <mi-rg> \
–name <mi-vmss> \
–output table
# Confirmar SKU activo de una instancia específica (Uniform orchestration)
az vmss show \
–resource-group <mi-rg> \
–name <mi-vmss> \
–instance-id <0> \
–query «sku.name» \
–output tsv
# Para Flexible orchestration: las instancias son VMs estándar; usar az vm show
az vm show \
–resource-group <mi-rg> \
–name <nombre-instancia-vmss> \
–query «hardwareProfile.vmSize» \
–output tsv
7. Confirmar que las nuevas instancias que escalen horizontalmente nacen ya con el SKU destino. Si tienes autoscale configurado, lanza un test de escalado manual y verifica el SKU de la instancia nueva.
# Escalar manualmente una instancia para verificar que nace con el nuevo SKU
az vmss scale \
–resource-group <mi-rg> \
–name <mi-vmss> \
–new-capacity <N+1>
# Ver el SKU de la instancia recién creada
az vmss list-instances \
–resource-group <mi-rg> \
–name <mi-vmss> \
–query «[-1].{id:instanceId, sku:sku.name, latestModel:latestModelApplied}» \
–output table
8. Verificar que las reglas de autoscale siguen siendo correctas: el mínimo y máximo de instancias no se han modificado, y el nuevo SKU tiene capacidad de cómputo suficiente para las métricas de escalado (un SKU con menos vCPUs puede hacer que el umbral de CPU se alcance más rápidamente).
# Ver la configuración de autoscale asociada al VMSS
az monitor autoscale list \
–resource-group <mi-rg> \
–query «[?contains(targetResourceUri, ‘<mi-vmss>’)]» \
–output table
9. Re-verificar extensiones y custom data tras la actualización. En Uniform orchestration, update-instances aplica el último modelo a las instancias seleccionadas; según el cambio, puede implicar actualización, recreación o reimage, y debe validarse como operación disruptiva. Las extensiones se reinstalan automáticamente desde el modelo del VMSS, pero conviene confirmar que todas están en estado «Provisioning succeeded». Para ver el estado de extensiones usa az vmss get-instance-view con –instance-id (ver el bloque de comandos más abajo), o az vmss extension list para listar las extensiones configuradas en el modelo del VMSS. Fuentes: learn.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set / learn.microsoft.com/cli/azure/vmss
# Ver extensiones configuradas en el modelo del VMSS
az vmss extension list \
–resource-group <mi-rg> \
–vmss-name <mi-vmss> \
–output table
# Ver extensiones aplicadas a una instancia específica del VMSS
az vmss get-instance-view \
–resource-group <mi-rg> \
–name <mi-vmss> \
–instance-id <instance-id> \
–query «extensions[].{name:name, status:statuses[-1].code}» \
–output table
Nota: El mini-runbook VMSS está basado en la documentación oficial de: learn.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set y learn.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-policy. La diferencia entre Uniform y Flexible orchestration está documentada en learn.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-orchestration-modes.
Checklist accionable: cierre de la operación
Las migraciones de VM por retiro de series son operaciones que parecen triviales hasta que no lo son. El resize en sí lleva minutos; la preparación correcta puede llevar horas o días, dependiendo de la complejidad del entorno. Antes de cerrar el ticket de cambio, marca cada punto de esta lista.
- [ ] He completado la ficha de ejecución por VM antes de iniciar la operación.
- [ ] He revisado el árbol de decisión y sé exactamente qué tipo de resize tengo.
- [ ] He verificado todas las stop conditions ninguna está activa.
- [ ] He identificado todas las VMs, VMSS, nodos AKS, Batch pools, host pools AVD e imágenes custom que usan series retiradas o anunciadas usando la query de Azure Resource Graph y Azure Advisor.
- [ ] He verificado si alguna VM está en Availability Set (AS) o PPG y he coordinado el impacto con los propietarios.
- [ ] He comprobado si la VM usa disco temporal (D:) y si el SKU destino también lo tiene.
- [ ] He movido el pagefile.sys a C: antes de migrar de Windows con-disco a sin-disco (si aplica).
- [ ] He verificado que el SKU destino tiene el mismo tipo de controladora (SCSI/NVMe) o, si cambia a v6/v7, que el SO es Gen2 y compatible con NVMe y que MANA está instalado.
- [ ] He tomado un snapshot de todos los discos antes de cualquier operación y he revisado el nivel de consistencia necesario para mi workload.
- [ ] He verificado la disponibilidad del SKU destino en la región y zona objetivo.
- [ ] He solicitado cuota adicional si el SKU destino requiere familia nueva.
- [ ] He gestionado las RI activas (canje o conversión a Savings Plan) si aplica.
- [ ] He calculado el impacto de coste con Azure Pricing Calculator o Retail Prices API (PAYG vs AHB vs RI/Savings Plan) antes de decidir el SKU objetivo.
- [ ] He activado o planificado Azure Hybrid Benefit si paso de B-series a D/E-series con Windows (mínimo 8 licencias de núcleo con Software Assurance activo).
- [ ] He actualizado los nodos del Azure-SSIS IR si usaban Standard_D*_v2 o Standard_A*_v2 (Stop → Set → Start).
- [ ] Para HBv2 y HC-series: he validado MPI, InfiniBand y benchmark de workload en el target antes de migrar producción.
- [ ] Para VMSS: he seguido el mini-runbook dedicado y he verificado el orchestration mode y la upgradePolicy.
- [ ] He ejecutado la validación post-resize Azure-side Y guest-side.
- [ ] He validado que el tamaño realmente cambió (no solo en el modelo): la VM arrancó, la aplicación responde y las métricas del SO confirman el nuevo SKU.
- [ ] He documentado el SKU original y los IDs de snapshot para poder ejecutar el rollback si es necesario.
- [ ] He verificado que todos los ítems de la checklist de rollback están documentados antes de cerrar la ventana de mantenimiento.
Fuentes oficiales consultadas
- Lista de series retiradas: learn.microsoft.com/azure/virtual-machines/sizes/retirement/retired-sizes-list
- Lista de series previous-gen (D/DS v1, B v1, Dv2, Dsv2 y otros): learn.microsoft.com/azure/virtual-machines/sizes/previous-gen-sizes-list
- Migration Guide unificada (D, Ds, Dv2, Dsv2, Av2, B, F, G, Ls, Lsv2, HBv2): learn.microsoft.com/azure/virtual-machines/migration/sizes/d-ds-dv2-dsv2-ls-series-migration-guide
- Bv1-series specs (SKUs confirmados: B1ls2, B1s, B1ms, B2s, B2ms, B4ms, B8ms, B12ms, B16ms, B20ms): learn.microsoft.com/azure/virtual-machines/sizes/general-purpose/bv1-series
- Dv2-series specs (D1_v2–D5_v2): learn.microsoft.com/azure/virtual-machines/sizes/general-purpose/dv2-series
- Dsv2-series specs (DS1_v2–DS5_v2): learn.microsoft.com/azure/virtual-machines/sizes/general-purpose/dsv2-series
- Msv2/Mdsv2 retirement (M192 SKUs): learn.microsoft.com/azure/virtual-machines/sizes/retirement/msv2-mdsv2-retirement
- NVv3 retirement: learn.microsoft.com/azure/virtual-machines/sizes/gpu-accelerated/nvv3-series-retirement
- NVv4 retirement: learn.microsoft.com/azure/virtual-machines/sizes/gpu-accelerated/nvv4-retirement
- NP-series retirement: learn.microsoft.com/azure/virtual-machines/sizes/retirement/np-series-retirement
- HBv2-series (retiro 31/05/2027, reemplazos HBv5/HX/HBv4/HBv3): learn.microsoft.com/azure/virtual-machines/sizes/high-performance-compute/hbv2-series
- HC-series (retiro 31/05/2027, reemplazos HBv5/HX): learn.microsoft.com/azure/virtual-machines/sizes/high-performance-compute/hc-series
- HC-series retirement guide: learn.microsoft.com/azure/virtual-machines/sizes/retirement/hc-series-retirement
- NVMe overview (SCSI vs NVMe por generación): learn.microsoft.com/azure/virtual-machines/nvme-overview
- Supported OS images for NVMe: learn.microsoft.com/azure/virtual-machines/enable-nvme-interface
- Remote NVMe FAQ (workaround SCSI→NVMe, script azure-nvme-VM-update.ps1): learn.microsoft.com/azure/virtual-machines/enable-nvme-remote-faqs
- MANA (Microsoft Azure Network Adapter): learn.microsoft.com/azure/virtual-network/accelerated-networking-mana-overview
- FAQ — VMs sin disco temporal (restricción Windows temp/diskless): learn.microsoft.com/azure/virtual-machines/azure-vms-no-temp-disk
- Resize a VM (incluye advertencia de resize fallido): learn.microsoft.com/azure/virtual-machines/sizes/resize-vm
- Snapshot consistency — crash-consistent, file-system-consistent, application-consistent, VSS writers y pre/post scripts: learn.microsoft.com/azure/backup/backup-azure-vms-introduction
- Azure Hybrid Benefit for Windows Server (AHB, requisitos, mínimo 8 cores, sin reinicio): learn.microsoft.com/azure/virtual-machines/windows/hybrid-use-benefit-licensing
- Azure-SSIS IR performance config: learn.microsoft.com/azure/data-factory/configure-azure-ssis-integration-runtime-performance
- Create Azure-SSIS IR: learn.microsoft.com/azure/data-factory/create-azure-ssis-integration-runtime
- VMSS upgrade scale set (az vmss update, update-instances): learn.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set
- VMSS upgrade policy (Manual, Automatic, Rolling): learn.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-policy
- VMSS orchestration modes (Uniform vs Flexible): learn.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-orchestration-modes
- Azure Pricing Calculator: azure.microsoft.com/pricing/calculator/
- Azure Retail Prices API: learn.microsoft.com/azure/retail-prices/azure-retail-prices
Artículo basado en documentación oficial de Microsoft Learn, herramientas oficiales de Azure y guías operativas referenciadas por Microsoft · Mayo 2026