Virtual switch: optimiser le réseau des machines virtuelles

Un virtual switch paraît discret tant que tout fonctionne. Pourtant, c’est lui qui décide comment les machines virtuelles parlent entre elles, comment elles sortent vers le réseau physique et quelles règles s’appliquent à leurs flux. Une mauvaise configuration peut créer de la latence, exposer un réseau interne ou rendre une migration de VM pénible.

Pour une PME, l’objectif n’est pas de complexifier l’infrastructure. Il est de choisir le bon type de commutateur virtuel, de documenter les VLAN, de limiter les droits et de surveiller les signaux simples : débit, erreurs, saturation et isolement. Le virtual switch devient utile quand il rend le réseau des VM lisible, pas quand il ajoute une couche obscure.

Commencez par le rôle réel. Un switch virtuel n’est utile que si son périmètre reste compréhensible.

À quoi sert un virtual switch ?

Le principe est simple. La difficulté vient surtout des choix d’exposition et de séparation.

Un virtual switch est un commutateur logiciel intégré à l’hyperviseur. Il joue le rôle d’un switch réseau pour les machines virtuelles, mais il fonctionne dans le serveur physique. Il peut connecter une VM à Internet, la relier à d’autres VM, isoler un réseau de test ou faire passer le trafic vers une carte réseau physique.

Cette nuance évite un contresens fréquent. Tout le trafic VM ne mérite pas de sortir du serveur.

La différence avec un switch matériel est importante. Le trafic entre deux VM hébergées sur le même serveur peut rester dans l’hôte. Il n’a pas besoin de sortir vers le réseau physique. Cette circulation locale réduit la latence et évite de charger inutilement les équipements réseau, à condition que le virtual switch soit bien conçu.

Le piège classique consiste à créer un seul grand réseau virtuel pour tout le monde. C’est rapide au départ, mais cela mélange administration, production, tests et parfois sauvegardes. Un virtual switch bien pensé crée des zones compréhensibles : production, management, stockage, laboratoire ou DMZ selon les besoins réels.

Cette logique devient encore plus importante quand l’hôte porte plusieurs rôles. Une VM applicative n’a pas les mêmes exigences qu’une VM de sauvegarde, qu’un contrôleur de domaine ou qu’un environnement de test. Si tous les flux passent par le même chemin, le dépannage devient confus : une lenteur applicative peut venir d’une sauvegarde, d’une migration, d’un pilote de carte ou d’une règle VLAN oubliée.

Un bon design commence donc par un dessin simple. Notez les cartes physiques, les switches virtuels, les VLAN, les VM critiques et les flux sensibles. Ce schéma n’a pas besoin d’être élégant ; il doit être exact. Sans cette vue, chaque modification ressemble à un pari.

L’inventaire donne une base de discussion. Il évite les décisions prises sur une mémoire partielle.

Complétez ce schéma par un inventaire exportable. Sur Hyper-V, quelques commandes PowerShell permettent déjà de lister les switches, les cartes VM et certains paramètres utiles. L’intérêt n’est pas de tout automatiser immédiatement, mais de figer un état de départ avant d’intervenir.

Get-VMSwitch
Get-VMNetworkAdapter -All
Get-VMNetworkAdapterVlan -VMName "*"

Gardez cet export dans le dossier de changement. Si la modification se passe mal, vous aurez une référence concrète plutôt qu’un souvenir approximatif. C’est particulièrement utile quand plusieurs administrateurs ont travaillé sur l’hôte au fil du temps.

La première décision est donc simple : quel flux doit sortir du serveur, quel flux doit rester local et quel flux doit être isolé ? Tant que cette réponse n’est pas claire, la configuration risque de devenir une accumulation de ports et de noms difficiles à maintenir.

Choisir le bon type de virtual switch

Le choix du type doit rester volontaire. Un switch externe n’est pas un choix par défaut.

Pour approfondir ce point, consultez tester un port avec telnet, qui traite plus précisément de tester un port réseau avec telnet sans mal interpréter le résultat.

Sur Hyper-V, un commutateur externe sert aux VM qui doivent communiquer avec le réseau de l’entreprise. Il est lié à une carte réseau physique ou à un team de cartes. C’est souvent le choix pour les serveurs applicatifs, les VM bureautiques ou les environnements qui doivent rejoindre un domaine.

Ces réseaux fermés sont utiles. Ils deviennent dangereux si leur objectif n’est plus connu.

Le commutateur interne est différent : il permet une communication entre les VM et l’hôte, sans exposer directement les VM au réseau physique. Il peut convenir pour un laboratoire, un réseau de maintenance ou des tests qui doivent rester accessibles depuis l’hôte. Le commutateur privé va plus loin : seules les VM connectées à ce switch peuvent communiquer entre elles.

La bonne pratique consiste à éviter les noms génériques. Un nom comme vSwitch-Prod-10G ou vSwitch-Lab-Isolated indique déjà l’usage, le périmètre et parfois la capacité. Ce détail réduit les erreurs quand plusieurs administrateurs interviennent.

Si l’hôte dispose de plusieurs cartes réseau, évitez de les consommer sans stratégie. Vous pouvez réserver une carte ou une équipe de cartes à la production, une autre aux sauvegardes ou à l’administration, selon la taille de l’environnement. Dans une petite structure, tout ne mérite pas une séparation physique, mais les flux critiques doivent être identifiés avant de saturer le premier lien disponible.

Le nommage doit rester lisible par un remplaçant. Évitez les abréviations internes que seule l’équipe historique comprend. Un bon nom indique l’usage, pas seulement la technologie : production, sauvegarde, lab, DMZ, management. Cette discipline paraît basique, mais elle accélère chaque dépannage.

Get-VMSwitch
New-VMSwitch -Name "vSwitch-Lab-Isolated" -SwitchType Private

La segmentation doit rester volontaire. Chaque VLAN ajouté doit correspondre à un besoin que l’équipe sait expliquer.

VLAN, sécurité et qualité de service

Les VLAN permettent de segmenter les flux. Ils ne remplacent pas un pare-feu, mais ils évitent de mélanger des réseaux qui n’ont pas les mêmes risques. Une VM d’administration, une VM exposée, un serveur de fichiers et un réseau de sauvegarde ne devraient pas partager le même espace logique sans raison.

La sécurité se joue aussi sur les options de port. Selon l’hyperviseur, vous pouvez contrôler le spoofing d’adresse MAC, les ACL, les extensions de switch ou certaines protections autour du trafic invité. La règle reste la même : activez ce que vous comprenez, documentez pourquoi, puis testez. Une protection mal comprise peut couper un service critique.

La QoS devient utile quand plusieurs VM se disputent la même carte réseau. Elle peut limiter un flux trop bavard ou réserver de la bande passante à une charge importante. Ne l’activez pas au hasard. Mesurez d’abord le trafic et identifiez le flux qui crée la contention.

Get-VMNetworkAdapter -VMName "VM-Applicative"
Set-VMNetworkAdapterVlan -VMName "VM-Applicative" -Access -VlanId 20

Ces commandes illustrent la logique, mais elles doivent être adaptées à votre environnement. Avant toute modification, notez l’état actuel, prévoyez un retour arrière et évitez d’appliquer une règle VLAN à distance sur la seule interface qui vous permet d’administrer l’hôte.

Le VLAN doit être traçable. Sans cela, le dépannage devient une chasse aux hypothèses.

La documentation doit préciser où le VLAN est défini : côté VM, côté port virtuel, côté switch physique ou côté routeur. Beaucoup d’incidents viennent d’une règle appliquée au mauvais endroit. Le réseau virtuel et le réseau physique doivent raconter la même histoire, sinon les paquets se perdent dans une configuration que personne ne revendique.

La QoS n’est pas magique. Elle arbitre une ressource limitée, elle ne crée pas de débit.

Pour la QoS, commencez par observer. Un débit limité sans mesure peut masquer un problème plus simple : sauvegarde mal planifiée, VM trop bavarde, carte réseau ancienne ou trafic de stockage mélangé à la production. La qualité de service doit répondre à une contention réelle, pas à une inquiétude générale.

La performance se mesure avant de se régler. Sans mesure, chaque optimisation devient une hypothèse fragile.

Performance : ce qu’il faut réellement surveiller

La lenteur a toujours un contexte. Heure, VM concernée et chemin réseau comptent autant que le débit.

Un virtual switch n’est pas automatiquement lent ou rapide. Sa performance dépend de la carte physique, du pilote, de l’hyperviseur, du nombre de VM, du type de trafic et des fonctions activées. Les problèmes viennent souvent d’un lien saturé, d’une segmentation confuse ou d’un trafic de sauvegarde qui traverse le même chemin que la production.

Surveillez les compteurs réseau côté hôte, les erreurs sur les cartes, les pics de bande passante, la latence applicative et les heures de sauvegarde. La question n’est pas seulement “combien de débit passe ?”, mais “quel flux perturbe quel service ?”. Cette lecture évite d’acheter une carte réseau plus rapide alors que le vrai problème est un mauvais chemin réseau.

Le diagnostic doit suivre une séquence stable. Regardez d’abord si le problème touche une seule VM, plusieurs VM du même hôte ou plusieurs hôtes. Vérifiez ensuite le VLAN, l’adresse IP, la passerelle, le DNS, la charge de la carte physique et les événements de l’hyperviseur. Cette méthode évite de modifier le virtual switch alors que la cause se trouve dans l’OS invité ou dans le réseau amont.

Un test simple consiste à comparer deux VM placées sur le même switch virtuel et deux VM qui doivent sortir par le réseau physique. Si le trafic local est fluide mais que le trafic externe est lent, la piste se déplace vers la carte, le pilote, le switch physique ou le routage. Si tout est lent, regardez plutôt la charge de l’hôte, les extensions réseau ou les paramètres communs.

Le changement réseau exige une marge. Une console de secours vaut mieux qu’un plan parfait inaccessible.

Déployer sans casser la production

Le plan protège surtout l’accès d’administration. Sans lui, une correction peut devenir une coupure.

Ne modifiez pas un virtual switch de production sans plan. Commencez par inventorier les VM connectées, les VLAN utilisés, les cartes physiques, les règles particulières et les dépendances. Ensuite, reproduisez la configuration dans un environnement pilote ou sur une fenêtre de maintenance limitée.

La migration d’un réseau virtuel doit être traitée comme une opération d’infrastructure. Prévenez les utilisateurs concernés, exportez la configuration si possible, notez les commandes de retour arrière et gardez une console locale ou hors bande disponible. Un changement réseau raté peut vous couper du serveur que vous cherchez à réparer.

Le plan de retour arrière doit être écrit avant la fenêtre de changement. Il indique quel switch recréer, quelle carte rattacher, quel VLAN remettre et comment vérifier que les VM critiques répondent. Si cette procédure n’est pas claire, le changement n’est pas prêt. Une configuration réseau virtuelle peut se modifier vite, mais elle peut aussi couper vite.

Après modification, ne vous contentez pas d’un ping. Testez une application, un accès fichier, une sauvegarde ou une connexion métier représentative. Le réseau peut répondre tout en étant mal segmenté ou trop lent pour l’usage réel. La validation doit porter sur le service rendu, pas seulement sur la connectivité brute. Notez aussi l’heure du test, la VM utilisée et le résultat observé.

Les erreurs les plus coûteuses sont souvent silencieuses. Elles apparaissent quand une migration ou une sauvegarde force le trafic.

Erreurs fréquentes à éviter

La première erreur est de nommer les switches sans convention. Six mois plus tard, personne ne sait lequel porte la production, lequel sert au lab et lequel dépend d’une ancienne carte réseau. La deuxième est de mélanger tous les flux sur un seul switch externe. Cela fonctionne, jusqu’au jour où un incident de sauvegarde ou une VM bavarde perturbe toute la plateforme.

La troisième erreur est de confondre isolation logique et sécurité complète. Un VLAN aide à séparer, mais il doit s’inscrire dans une architecture plus large : pare-feu, droits d’administration, supervision, mises à jour et documentation. Le virtual switch n’est qu’un composant. Il est central, mais il ne porte pas seul toute la sécurité.

La priorité concrète : choisissez une convention de nommage, limitez les types de switch, documentez les VLAN et surveillez les premiers changements. Une infrastructure virtuelle fiable vient rarement d’une configuration spectaculaire. Elle vient d’un réseau virtuel simple, lisible et vérifié.

Commencez par retirer le flou. L’optimisation vient ensuite, quand les dépendances sont visibles.

Pour commencer, auditez l’existant avant d’ajouter une option. Listez les switches, les VM connectées, les VLAN et les cartes physiques utilisées. Supprimez seulement ce qui est clairement inutilisé, et gardez une trace des anciennes configurations. Cette étape de nettoyage apporte souvent plus de stabilité qu’un réglage avancé ajouté trop tôt.

Désignez enfin un responsable du réseau virtuel. Sans propriétaire clair, les changements s’accumulent et personne ne sait quelle règle peut être retirée.

Pour approfondir ce point, consultez Angry IP Scanner, qui traite plus précisément de angry ip scanner pour inventorier un réseau local sans scanner n’importe quoi.