Objectif
Créer un vSwitch Hyper-V externe connecté au réseau physique, en préservant la connectivité de l’hôte lorsque nécessaire, en documentant les VLAN et les dépendances de la carte réseau, puis en validant le chemin complet depuis une VM pilote avant de migrer les autres interfaces virtuelles.
Prérequis
- Rôle Hyper-V installé et accès administrateur local ou PowerShell élevé.
- Nom exact de la carte physique destinée au vSwitch et confirmation de son câblage vers le bon switch.
- Plan VLAN : réseau non tagué ou VLAN ID pour le Management OS et pour les VM concernées.
- Sauvegarde
- Accès console/iLO/iDRAC ou seconde NIC si l’hôte est administré à distance.
Procédure pas à pas
Capturer l’état réseau de l’hôte
Avant de toucher aux bindings, listez les cartes, leurs noms, leur état, leurs adresses IP et les commutateurs Hyper-V déjà présents. Identifiez la NIC qui porte actuellement l’administration. Si elle possède des IP statiques, notez-les précisément. Cette capture permet de distinguer une perte de connectivité liée au rebinding d’un problème de VLAN ou de passerelle après création du vSwitch.
Get-NetAdapter | Sort-Object NameGet-NetIPConfigurationGet-VMSwitch | Format-Table Name,SwitchType,NetAdapterInterfaceDescriptionGet-VMNetworkAdapter -ManagementOS- La carte physique cible et les vSwitch existants sont identifiés.
- La configuration IP de l’hôte est documentée avant le changement.
Vérifier que la carte physique est disponible
Confirmez que la NIC cible n’est pas déjà attachée à un autre commutateur externe et qu’elle n’appartient pas à une configuration de teaming que vous risqueriez de casser. Vérifiez aussi le débit, l’état du lien et le nom exact attendu par New-VMSwitch. Si le serveur possède plusieurs cartes identiques, utilisez la description, l’adresse MAC et le câblage pour éviter une erreur de sélection.
Get-NetAdapter | Format-Table Name,InterfaceDescription,Status,LinkSpeed,MacAddressGet-VMSwitch | Select-Object Name,NetAdapterInterfaceDescription,SwitchType- Une seule carte cible est retenue et son lien physique est UP.
- Aucun vSwitch existant ne dépend déjà de cette NIC.
Préparer le switch physique et le VLAN
Configurez le port du switch selon le design. Pour un seul réseau non tagué, un port access peut suffire. Pour plusieurs VLAN, utilisez un trunk et autorisez uniquement les VLAN nécessaires. Si le Management OS utilise un VLAN tagué, préparez ce VLAN avant la bascule afin que l’hôte ne perde pas son accès dès que l’interface vEthernet est créée.
- Le port physique transporte les VLAN attendus.
- Le VLAN d’administration éventuel est disponible avant la création du vSwitch.
Créer le vSwitch externe
Créez le commutateur avec un nom explicite. Spécifier NetAdapterName crée implicitement un vSwitch externe. Conservez AllowManagementOS à True si l’hôte doit continuer à utiliser cette interface physique via un adaptateur virtuel de management. Pour une interface entièrement dédiée au trafic VM, choisissez le comportement correspondant à votre architecture.
New-VMSwitch -Name "<VSWITCH-NAME>" -NetAdapterName "<PHYSICAL-NIC>" -AllowManagementOS $true- Get-VMSwitch affiche le nouveau commutateur de type External.
- Un adaptateur vEthernet correspondant apparaît pour le Management OS si AllowManagementOS est activé.
Note : La création peut provoquer une courte coupure réseau. Ne relancez pas immédiatement la commande si votre session distante se fige : vérifiez d’abord l’accès console.
Reconfigurer l’adressage du Management OS
Après le rebinding, l’adresse de management doit être portée par l’adaptateur vEthernet associé au vSwitch, et non par la NIC physique. Vérifiez si Windows a conservé la configuration IP attendue. Si l’hôte utilise une IP statique, appliquez-la sur le bon adaptateur virtuel, puis contrôlez DNS et passerelle. Ne créez pas deux passerelles par défaut concurrentes.
Get-NetAdapter -Name "vEthernet (<VSWITCH-NAME>)"Get-NetIPConfiguration -InterfaceAlias "vEthernet (<VSWITCH-NAME>)"- L’hôte possède l’IP, le DNS et la passerelle attendus sur le vEthernet de management.
- La carte physique ne porte plus directement une configuration IP contradictoire.
Configurer le VLAN du Management OS si nécessaire
Si le réseau d’administration est tagué, configurez le VLAN sur l’adaptateur virtuel de management. N’appliquez pas un VLAN ID si le port physique présente ce réseau en non tagué/native VLAN. Après modification, testez immédiatement la passerelle et une ressource d’administration avant de poursuivre.
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "<MANAGEMENT-ADAPTER-NAME>" -Access -VlanId <VLAN-ID>Get-VMNetworkAdapterVlan -ManagementOS- Le VLAN affiché correspond au design.
- L’administration de l’hôte reste joignable.
Connecter une VM pilote et valider son VLAN
Connectez une seule VM au nouveau vSwitch. Si elle doit appartenir à un VLAN access, configurez son VLAN ID sur l’adaptateur virtuel. Démarrez la VM et contrôlez adresse IP, passerelle, DNS et accès aux ressources prévues. Cette étape sépare un problème de vSwitch d’un problème de trunk physique ou de configuration invité.
Connect-VMNetworkAdapter -VMName "<VM-PILOT>" -SwitchName "<VSWITCH-NAME>"Set-VMNetworkAdapterVlan -VMName "<VM-PILOT>" -Access -VlanId <VLAN-ID>Get-VMNetworkAdapterVlan -VMName "<VM-PILOT>"- La VM pilote obtient le réseau attendu.
- Le trafic autorisé fonctionne sans modifier les autres VM.
Migrer progressivement les autres VM
Une fois la VM pilote validée, connectez les autres VM par petits groupes. Pour chacune, vérifiez le VLAN avant de détacher son ancienne connectivité. Sur un cluster, assurez-vous que le nom du vSwitch et le design réseau sont cohérents sur tous les nœuds susceptibles d’héberger les VM ; sinon une migration ou un redémarrage sur un autre hôte peut couper le réseau.
Get-VMNetworkAdapter | Select-Object VMName,Name,SwitchName,Status- Chaque VM migrée utilise le vSwitch et le VLAN prévus.
- Aucune VM restante ne dépend involontairement d’un ancien commutateur.
Documenter et surveiller après changement
Conservez le nom du vSwitch, la NIC physique, le port de switch, les VLAN, la configuration du Management OS et les VM associées. Surveillez les erreurs de carte, pertes de lien et événements Hyper-V pendant la période de validation. Si le changement est réalisé sur plusieurs nœuds, comparez les configurations avant de déclarer l’opération terminée.
Get-VMSwitchGet-VMNetworkAdapter -ManagementOSGet-NetAdapterStatistics- La configuration finale est reproductible.
- Les compteurs réseau ne montrent pas d’erreur anormale après migration.
Validation
La procédure est validée lorsque :
- Le vSwitch est de type External et attaché à la NIC physique prévue.
- Le Management OS conserve sa connectivité si cela fait partie du design.
- La VM pilote puis les VM migrées utilisent les bons VLAN et atteignent les ressources attendues.
- La configuration du switch physique, du vSwitch et des VLAN est documentée de façon cohérente.
Retour arrière
- Reconnecter les VM à l’ancien vSwitch si celui-ci est toujours disponible et stable.
- Si l’accès de l’hôte est perdu, utiliser la console hors bande pour restaurer l’IP/VLAN du Management OS ou recréer l’ancienne configuration.
- Supprimer le nouveau vSwitch uniquement après avoir déconnecté ou migré toutes les VM qui l’utilisent.
- Restaurer la configuration du port physique et les bindings réseau documentés avant l’intervention si le nouveau design doit être abandonné.
Dépannage / erreurs fréquentes
- Création refusée car la carte est déjà liée à un autre réseau virtuel : identifier le vSwitch existant ou le teaming avant de forcer une modification.
- Hôte inaccessible après création : vérifier l’IP portée par vEthernet, le VLAN de management, le trunk physique et la passerelle.
- VM sans réseau mais hôte accessible : comparer le VLAN de la VM et les VLAN autorisés sur le trunk.
- Un seul nœud de cluster fonctionne : homogénéiser nom du vSwitch, VLAN et uplinks sur les hôtes concernés.
- Débit ou pertes anormales : contrôler le lien physique, erreurs NIC, teaming/SET éventuel et négociation du switch.