Depuis Windows Server 1903 et 1909, les switchs virtuels d'Hyper-V sur un agrégat de cartes réseau de type LBFO sont dépréciés (voir la documentation). La technologie reste supportée, mais elle n'évoluera. Il est conseillé de créer un agrégat de type SET.

Dans la pratique

Le SET est une technologie très intéressante qui a cependant quelques contraintes. Les interfaces utilisées doivent avoir des caractéristiques identiques :

• Fabriquant
• Model
• Vitesse du lien
• Configuration

Même si ces contraintes ne semblent pas énormes, on est très loin de la souplesse du LBFO Teaming. Pour rappel, celui-ci n'a absolument aucune contrainte.

Dans la pratique le SET est conseillé avec des interfaces réseau de 10Gb ou plus. On est donc très loin de la cible visée par le LBFO (utilisation de la totalité des cartes intégrées à carte mère pro, Home Lab, refurbish).

Si l'on ne peut pas utiliser SET

Depuis Windows Server 2022, il n'est pas possible d'utiliser la console de gestion d'Hyper-V pour créer un switch virtuel avec LBFO. Il est cependant possible d'utiliser PowrShell pour créer ce switch.

Voici l'exemple pour la création d'un switch pour un Home Lab:

New-VMSwitch -Name "LAN" -NetAdapterName "Team" -AllowNetLbfoTeams $true -AllowManagementOS $true

Dans le détails :

• Le switch portera le nom "LAN"
• L'agrégat de carte réseau porte le nom "Team"
• L'agrégat reste utilisable pour accéder à l'hôte Hyper-V (Attention : totalement déconseillé hors d'un Lab)

QUID de la migration

Dans le contexte d'une migration sur place, Hyper-V ne pose pas de problèmes. Ces dernières années, j'ai migré deux de mes Hyper-V utilisant LBFO je n'ai pas rencontré le moindre problème. Les deux serveurs on tournée successivement sous 2012 R2, 2016, 2019 et 2022 sans jamais perdre leurs switchs virtuels (je passe les versions précédentes, car elles n'utilisaient pas de NIC Teaming).