Azure retire les séries Dv3, Dsv3, Ev3 et Esv3 le 15 novembre 2029

Microsoft a publié le 30 septembre 2026, dans les Azure Updates, le retrait des séries de machines virtuelles Dv3, Dsv3, Ev3 et Esv3 dans les régions Azure du cloud public. Les quatre séries entrent dans l’étape End of Life du cycle de vie des tailles de machines virtuelles et sont retirées le 15 novembre 2029. Le retrait touche les 32 tailles de ces séries et ne s’applique ni à Azure Government, ni à Azure opéré par 21Vianet, ni aux régions des clouds souverains.

Les machines existantes continuent de tourner et restent prises en charge jusqu’à cette date. Trois autres échéances arrivent bien avant 2029 pour qui exploite encore ces séries : les restrictions de capacité, en vigueur depuis juillet 2026 ; la fin des réservations, depuis le 1er juillet 2026 ; et le changement de la politique d’échange des réservations, le 1er février 2027.

Dates relevées le 12 octobre 2026 sur la documentation Microsoft.

Ce qui arrive aux machines le 15 novembre 2029

À la date de retrait, Microsoft désalloue les machines virtuelles qui tournent encore sur une série retirée. Elles cessent de fonctionner, cessent d’être facturées, et ne sont plus couvertes ni par un SLA ni par le support. Les données en mémoire et sur le disque temporaire sont perdues ; les données des disques managés sont conservées. Pour reprendre le service, il faut redimensionner la machine vers une taille prise en charge et la redémarrer.

L’annonce des Azure Updates ajoute que les machines non migrées peuvent être désallouées et, à terme, supprimées à mesure que le matériel et l’infrastructure de plateforme sous-jacents sont retirés. La documentation du cycle de vie décrit, elle, la désallocation et la conservation des disques managés. Dans les deux cas, une machine qui n’a pas changé de taille avant le 15 novembre 2029 s’arrête.

Les restrictions de capacité s’appliquent depuis juillet 2026

Indépendamment du retrait, les séries Dv3, Dsv3, Ev3 et Esv3 sont soumises à des restrictions de croissance de capacité depuis juillet 2026. Un nouvel abonnement ne peut pas déployer ces séries. Un abonnement existant peut continuer à déployer et redéployer dans la limite de son quota déjà approuvé, sous réserve de capacité disponible ; une demande de quota supplémentaire n’est pas approuvée.

Le quota est une limite approuvée, pas une garantie de capacité : un déploiement peut échouer sur une erreur d’allocation si la région ou la zone n’a plus de matériel disponible, même avec du quota. Une réservation ne protège pas de cette situation. Microsoft rappelle qu’une Reserved VM Instance est un avantage de facturation et non une réservation de capacité : elle ne garantit ni la création, ni le redéploiement, ni la reprise après sinistre, ni le basculement si la capacité manque. Microsoft recommande aux clients qui ont besoin d’une capacité garantie d’évaluer les on-demand capacity reservations.

Un plan de reprise après sinistre qui prévoit de recréer des machines de ces quatre séries dans une autre région repose donc sur une capacité que Microsoft ne garantit pas. Microsoft demande de revoir les plans de reprise après sinistre et de restauration, et de mettre à jour les réservations, les savings plans et la stratégie de capacité en fonction de l’environnement cible.

Réservations : échange limité après le 1er février 2027, passage en savings plan inchangé

Depuis le 1er juillet 2026, les réservations d’un an et de trois ans ne peuvent plus être achetées ni renouvelées pour ces quatre séries. Les réservations en cours continuent jusqu’à la fin de leur terme. Le fonctionnement des notifications d’expiration et l’ensemble des dix-huit séries concernées par cette fermeture sont détaillés dans l’article sur les réservations Azure des séries héritées.

Pour qui continue d’exploiter ces séries avant le retrait, Microsoft donne l’Azure savings plan for compute comme recommandation principale. Une réservation existante peut être échangée contre un savings plan : le nouveau savings plan, d’un an ou de trois ans, doit porter un engagement au moins égal à l’engagement restant de la réservation rendue, et jusqu’à 100 réservations peuvent être échangées en une seule opération. Microsoft ne facture actuellement pas de frais de résiliation anticipée sur ces échanges, et indique qu’il pourrait en facturer à l’avenir sans en donner la date. Microsoft précise aussi que le changement du 1er février 2027 ne modifie pas la politique d’échange d’une réservation contre un savings plan.

Une réservation peut aussi être échangée contre une réservation sur une série plus récente. L’engagement total de la nouvelle réservation doit être au moins égal à l’engagement restant de l’ancienne, et la nouvelle réservation repart pour un terme complet à compter de l’échange. Les échanges de réservations sont disponibles jusqu’au 1er février 2027 ; après cette date, chaque réservation active éligible achetée avant l’échéance garde un dernier échange. Microsoft demande de revoir le portefeuille de réservations avant le 1er février 2027 et de planifier l’usage de ce dernier échange pour chaque réservation éligible.

Une réservation ne suit pas la machine lors d’un redimensionnement vers une autre série. Sans échange ni passage en savings plan, la remise peut cesser de s’appliquer, ce qui peut entraîner des coûts supplémentaires.

Les séries cibles et ce qui change avec elles

Microsoft classe les séries en quatre étapes : Current, Extended, End of Life et Retired. Pour les tailles à usage général, v6 et v7 sont Current, v4 et v5 sont Extended, et les séries v1 à v3 dont le retrait est annoncé sont End of Life. Les séries Current et Extended sont toutes deux pleinement prises en charge.

Microsoft présente la génération v5 comme la transition la plus simple pour une charge existante, et les générations v6 et v7 comme la voie vers les fonctionnalités et performances les plus récentes.

Ce qui change en passant à la génération v5

Beaucoup de séries v5 de base, dont Dv5, Dsv5, Dasv5, Ev5, Esv5 et Easv5, n’ont pas de disque temporaire local, alors que chacune des 32 tailles Dv3, Dsv3, Ev3 et Esv3 en a un. Sous Windows, le redimensionnement n’est permis que d’une taille avec disque temporaire vers une taille avec disque temporaire, ou d’une taille sans vers une taille sans. Depuis une série v3, la cible directe sous Windows est donc une variante en d, comme Ddsv5 ou Eadsv5 ; viser Dsv5 ou Esv5 passe par le contournement que Microsoft documente, par instantané du disque puis création d’une nouvelle machine. Sous Linux, le redimensionnement entre les deux catégories est pris en charge.

Accelerated Networking est obligatoire sur les séries Intel D v5, soit Dv5, Dsv5, Ddv5 et Ddsv5, et pris en charge sur les séries AMD et sur la famille E v5. Microsoft demande de l’activer sur la machine source avant de la redimensionner vers une série qui l’exige. Les séries v5 des familles D et E prennent en charge les machines de génération 1 et de génération 2 : un changement de génération n’est en principe pas nécessaire pour un redimensionnement.

Ce qui change en passant à la génération v6 ou v7

Les séries v6 et v7 démarrent en génération 2, donc en UEFI, présentent les disques en NVMe et utilisent l’adaptateur réseau MANA, qui demande un système et des pilotes à jour. L’image doit être une image de génération 2 prête pour NVMe et MANA. Le disque local n’existe que sur les tailles en d, et il est lui aussi présenté en NVMe. Microsoft demande de traiter ce passage comme une mise à niveau planifiée, et non comme un redimensionnement en place fait sans préparation depuis une famille plus ancienne.

Deux limites s’ajoutent. Une machine dont les disques sont présentés en SCSI ne peut pas être redimensionnée directement vers une taille à NVMe distant ; Microsoft renvoie à une procédure de contournement. Et Azure Disk Encryption n’est pas disponible sur les séries v6 et v7, ni sous Windows ni sous Linux ; ce service est par ailleurs annoncé en retrait pour le 15 septembre 2028, et son remplaçant, encryption at host, ne peut pas être activé sur une machine qui a, ou a eu, Azure Disk Encryption. Dans ce cas, Microsoft prévoit une reconstruction avec de nouveaux disques et une nouvelle machine, pas une conversion.

Redimensionner une machine : la procédure et ce qu’elle interrompt

Le guide de modernisation de Microsoft décrit trois étapes : arrêter la machine en la désallouant, la redimensionner vers la série cible, puis la redémarrer. Avant cela, il faut vérifier que l’abonnement dispose de quota pour la série cible et en demander si besoin.

Avec Azure CLI, la commande az vm list-vm-resize-options --resource-group <groupe> --name <machine> --query "[].name" liste les tailles disponibles sur le cluster matériel qui héberge la machine. Si la taille voulue n’y figure pas, la désallocation permet à la machine d’être replacée sur un autre hôte. Le script de Microsoft enchaîne ensuite az vm deallocate, az vm resize --size <taille> et az vm start, chacun avec --resource-group et --name. En PowerShell, Get-AzVMSize -ResourceGroupName <groupe> -VMName <machine> donne la même liste, et le redimensionnement passe par la propriété HardwareProfile.VmSize de l’objet rendu par Get-AzVM, appliquée avec Update-AzVM.

Un redimensionnement redémarre la machine, même quand la désallocation n’est pas nécessaire. Microsoft le qualifie d’opération perturbatrice, en particulier pour une charge avec état. La désallocation libère les adresses IP dynamiques de la machine ; les disques de système et de données ne sont pas touchés. Dans un availability set, si la taille cible n’est pas disponible sur le cluster, toutes les machines du groupe doivent être désallouées pour le redimensionnement.

Si un redimensionnement échoue, le modèle de la machine affiche la taille demandée alors que la machine continue de tourner sur l’ancienne, jusqu’à ce que l’allocation réussisse. Le portail et toutes les lectures de l’API montrent la dernière configuration appliquée, pas la taille réellement en service.

Notre lecture

Nous ne traiterions pas ce retrait comme une échéance de 2029. Les deux dates qui engagent sont plus proches : le changement des règles d’échange des réservations le 1er février 2027, et la restriction de capacité déjà en vigueur, qui fragilise tout plan de reprise fondé sur la recréation de machines de ces séries ailleurs. L’inventaire se fait donc en deux listes, les réservations actives avec leur date d’expiration et les machines v3 avec leur dépendance au disque temporaire, à la génération de démarrage et à Azure Disk Encryption.

Pour une machine Windows, nous viserions la génération v5 par redimensionnement, vers une variante en d : les tailles v3 ont toutes un disque temporaire, et Windows n’accepte que le passage vers une taille qui en a un. Comme v5 accepte aussi la génération 1 et le SCSI, une image venue d’une conversion locale n’a pas à être reconstruite pour ce passage. Nous réserverions la génération v6 aux machines reconstruites depuis une image à jour, et à toute machine chiffrée par Azure Disk Encryption, qui devra quitter ce service avant le 15 septembre 2028 et que Microsoft fait passer à encryption at host par une reconstruction. Dans tous les cas, nous activerions Accelerated Networking et nous testerions le redimensionnement sur une machine sans état avant de toucher aux serveurs de base de données.

Ce qu’il faut vérifier

• La liste des machines en Dv3, Dsv3, Ev3 ou Esv3, par abonnement et par région, avec leur rôle dans un plan de reprise après sinistre.
• Les réservations actives sur ces séries, leur terme, et la décision d’échange avant le 1er février 2027, ou de passage en savings plan.
• Le quota disponible pour la série cible dans chaque région, avant tout redimensionnement.
• Le disque temporaire local, présent sur toutes les tailles v3 : sous Windows, le redimensionnement direct ne vise qu’une variante en d.
• L’activation d’Accelerated Networking sur la machine source avant un passage vers Dv5, Dsv5, Ddv5 ou Ddsv5.
• La génération de démarrage, le type de contrôleur de disque et la présence d’Azure Disk Encryption, qui décident entre redimensionnement et reconstruction.
• Les availability sets, dont toutes les machines peuvent devoir être désallouées ensemble.

Les sources Microsoft

• Retirement: Dv3, Dsv3, Ev3, and Esv3 Azure VMs — Azure Updates
• Retirement: Azure Reserved Virtual Machines Instances for select VM series — Azure Updates
• VM lifecycle overview — Microsoft Learn
• VM size series retirements, capacity growth restrictions, and modernization guidance — Microsoft Learn
• Retired VM sizes modernization guide — Microsoft Learn
• Modernize to the v5 VM series — Microsoft Learn
• Modernize to the v6 and v7 VM series — Microsoft Learn
• Frequently asked questions about modernization to v6 and v7 VM series — Microsoft Learn
• Resize a virtual machine — Microsoft Learn
• Self-service trade-in for savings plans — Microsoft Learn
• Self-service exchanges and refunds for Azure Reservations — Microsoft Learn