XenServer

Gérer la mise en réseau

August 1, 2026

Contributeur:

Les procédures de configuration réseau de cette section diffèrent selon que vous configurez un hôte autonome ou un hôte faisant partie d’un pool de ressources.

Créer des réseaux dans un hôte autonome

Étant donné que les réseaux externes sont créés pour chaque PIF lors de l’installation de l’hôte, la création de réseaux supplémentaires n’est généralement requise que pour :

Utiliser un réseau privé
Prendre en charge des opérations avancées telles que les VLAN ou l’agrégation de cartes réseau

Pour plus d’informations sur l’ajout ou la suppression de réseaux à l’aide de XenCenter, consultez Ajouter un nouveau réseau dans la documentation XenCenter.

Ouvrez la console texte de l’hôte XenServer®.

Créez le réseau à l’aide de la commande network-create, qui renvoie l’UUID du réseau nouvellement créé :

xe network-create name-label=mynetwork
<!--NeedCopy-->

À ce stade, le réseau n’est pas connecté à un PIF et est donc interne.

Créer des réseaux dans les pools de ressources

Tous les hôtes XenServer d’un pool de ressources doivent avoir le même nombre de cartes réseau physiques. Cette exigence n’est pas strictement appliquée lorsqu’un hôte est joint à un pool. L’une des cartes réseau est toujours désignée comme interface de gestion, utilisée pour le trafic de gestion XenServer.

Comme tous les hôtes d’un pool partagent un ensemble commun de réseaux, il est important d’avoir la même configuration réseau physique pour les hôtes XenServer d’un pool. Les PIF sur les hôtes individuels sont connectés aux réseaux du pool en fonction du nom de l’appareil. Le réseau X correspond à l’interface réseau en position X sous le modèle de nommage réseau Dom0.

Si un hôte XenServer a un nombre de cartes réseau différent des autres hôtes du pool, des complications peuvent survenir. Les complications peuvent survenir car tous les réseaux du pool ne sont pas valides pour tous les hôtes du pool. Par exemple, si les hôtes host1 et host2 sont dans le même pool et que host1 a quatre cartes réseau et host2 n’en a que deux, seuls les réseaux connectés aux PIF correspondant aux deux premières interfaces réseau de host1 sont valides sur host2. Les machines virtuelles sur host1 avec des VIF connectés aux réseaux correspondant aux interfaces réseau restantes ne peuvent pas migrer vers l’hôte host2.

Créer des VLAN

Pour les hôtes d’un pool de ressources, vous pouvez utiliser la commande pool-vlan-create. Cette commande crée le VLAN et crée et branche automatiquement les PIF requis sur les hôtes du pool. Pour plus d’informations, consultez pool-vlan-create.

Ouvrez la console de l’hôte XenServer.

Créez un réseau à utiliser avec le VLAN. L’UUID du nouveau réseau est renvoyé :

xe network-create name-label=network5
<!--NeedCopy-->

Utilisez la commande pif-list pour trouver l’UUID du PIF correspondant à la carte réseau physique prenant en charge l’étiquette VLAN souhaitée. Les UUID et les noms de périphérique de tous les PIF sont renvoyés, y compris les VLAN existants :

xe pif-list
<!--NeedCopy-->

Créez un objet VLAN spécifiant le PIF physique et l’étiquette VLAN souhaités sur toutes les machines virtuelles à connecter au nouveau VLAN. Un nouveau PIF est créé et branché au réseau spécifié. L’UUID du nouvel objet PIF est renvoyé.

xe vlan-create network-uuid=network_uuid pif-uuid=pif_uuid vlan=5
<!--NeedCopy-->

Attachez les VIF de VM au nouveau réseau. Pour plus d’informations, consultez Création de réseaux dans un hôte autonome.

Créer des liaisons de cartes réseau sur un hôte autonome

Nous vous recommandons d’utiliser XenCenter pour créer des liaisons de cartes réseau. Pour plus d’informations, consultez Configuration des cartes réseau.

Cette section explique comment utiliser l’interface de ligne de commande xe pour lier des interfaces de carte réseau sur des hôtes XenServer qui ne font pas partie d’un pool. Pour plus d’informations sur l’utilisation de l’interface de ligne de commande xe pour créer des liaisons de cartes réseau sur des hôtes XenServer qui composent un pool de ressources, consultez Création de liaisons de cartes réseau dans les pools de ressources.

Créer une liaison de carte réseau

Lorsque vous liez une carte réseau, la liaison absorbe le PIF/NIC utilisé comme interface de gestion. L’interface de gestion est automatiquement déplacée vers le PIF de liaison.

Utilisez la commande network-create pour créer un réseau à utiliser avec la carte réseau liée. L’UUID du nouveau réseau est renvoyé :
```
xe network-create name-label=bond0

```
Utilisez la commande pif-list pour déterminer les UUID des PIF à utiliser dans la liaison :
```
xe pif-list

```
Effectuez l’une des opérations suivantes :
- Pour configurer la liaison en mode actif-actif (par défaut), utilisez la commande bond-create pour créer la liaison. En utilisant des virgules pour séparer les paramètres, spécifiez l’UUID du réseau nouvellement créé et les UUID des PIF à lier :
```
 xe bond-create network-uuid=network_uuid /
      pif-uuids=pif_uuid_1,pif_uuid_2,pif_uuid_3,pif_uuid_4
 
```
  Saisissez deux UUID lorsque vous liez deux cartes réseau et quatre UUID lorsque vous liez quatre cartes réseau. L’UUID de l’agrégat est renvoyé après l’exécution de la commande.
- Pour configurer l’agrégat en mode actif-passif ou LACP, utilisez la même syntaxe, ajoutez le paramètre facultatif mode et spécifiez lacp ou active-backup :
```
 xe bond-create network-uuid=network_uuid pif-uuids=pif_uuid_1, /
      pif_uuid_2,pif_uuid_3,pif_uuid_4 /
      mode=balance-slb | active-backup | lacp
 
```

Contrôler l’adresse MAC de l’agrégat

Lorsque vous liez l’interface de gestion, elle englobe le PIF/NIC utilisé comme interface de gestion. Si l’hôte utilise le DHCP, l’adresse MAC de l’agrégat est la même que celle du PIF/NIC utilisé. L’adresse IP de l’interface de gestion peut rester inchangée.

Vous pouvez modifier l’adresse MAC de l’agrégat afin qu’elle soit différente de l’adresse MAC de la carte réseau d’interface de gestion (actuelle). Cependant, lorsque l’agrégat est activé et que l’adresse MAC/IP utilisée change, les sessions réseau existantes vers l’hôte sont interrompues.

Vous pouvez contrôler l’adresse MAC d’un agrégat de deux manières :

Un paramètre facultatif mac peut être spécifié dans la commande bond-create. Vous pouvez utiliser ce paramètre pour définir l’adresse MAC de l’agrégat sur n’importe quelle adresse arbitraire.
Si le paramètre mac n’est pas spécifié, XenServer utilise l’adresse MAC de l’interface de gestion si elle fait partie des interfaces de l’agrégat. Si l’interface de gestion ne fait pas partie de l’agrégat, mais qu’une autre interface de gestion en fait partie, l’agrégat utilise l’adresse MAC (ainsi que l’adresse IP) de cette interface de gestion. Si aucune des cartes réseau de l’agrégat n’est une interface de gestion, l’agrégat utilise l’adresse MAC de la première carte réseau nommée.

Annuler les agrégats de cartes réseau

Lors de la restauration de l’hôte XenServer à une configuration non agrégée, la commande bond-destroy configure automatiquement la carte réseau principale comme interface pour l’interface de gestion. Par conséquent, tous les VIF sont déplacés vers l’interface de gestion. Si l’interface de gestion d’un hôte se trouve sur une interface agrégée VLAN balisée, lors de l’exécution de bond-destroy, le VLAN de gestion est déplacé vers la carte réseau principale.

Le terme carte réseau principale fait référence au PIF à partir duquel la configuration MAC et IP a été copiée lors de la création de l’agrégat. Lors de l’agrégation de deux cartes réseau, la carte réseau principale est :

La carte réseau de l’interface de gestion (si l’interface de gestion est l’une des cartes réseau agrégées).
Toute autre carte réseau avec une adresse IP (si l’interface de gestion ne faisait pas partie de l’agrégat).
La première carte réseau nommée. Vous pouvez savoir de laquelle il s’agit en exécutant la commande suivante :
```
xe bond-list params=all

```

Créer des agrégats de cartes réseau dans des pools de ressources

Dans la mesure du possible, créez des liaisons de cartes réseau (NIC bonds) dans le cadre de la création initiale du pool de ressources, avant de joindre d’autres hôtes au pool ou de créer des machines virtuelles. Cela permet à la configuration de la liaison d’être automatiquement répliquée sur les hôtes lorsqu’ils sont joints au pool et réduit le nombre d’étapes requises.

L’ajout d’une liaison de carte réseau (NIC bond) à un pool existant nécessite l’une des opérations suivantes :

Utilisation de l’interface de ligne de commande (CLI) pour configurer les liaisons sur le coordinateur de pool, puis sur chaque membre du pool.
Utilisation de l’interface de ligne de commande (CLI) pour configurer les liaisons sur le coordinateur de pool, puis redémarrage de chaque membre du pool afin qu’il hérite de ses paramètres du coordinateur de pool.
Utilisation de XenCenter® pour configurer les liaisons sur le coordinateur de pool. XenCenter synchronise automatiquement les paramètres réseau des hôtes membres avec le coordinateur de pool, vous n’avez donc pas besoin de redémarrer les hôtes membres.

Pour des raisons de simplicité et pour éviter les erreurs de configuration, nous vous recommandons d’utiliser XenCenter pour créer des liaisons de cartes réseau (NIC bonds). Pour plus d’informations, consultez Configuration des cartes réseau.

Cette section décrit l’utilisation de l’interface de ligne de commande xe pour créer des interfaces de cartes réseau (NIC) liées sur les hôtes XenServer qui composent un pool de ressources. Pour plus d’informations sur l’utilisation de l’interface de ligne de commande xe pour créer des liaisons de cartes réseau sur un hôte autonome, consultez Création de liaisons de cartes réseau sur un hôte autonome.

Avertissement :

N’essayez pas de créer des liaisons réseau lorsque la haute disponibilité est activée. Le processus de création de liaison perturbe le battement de cœur de la haute disponibilité en cours et provoque l’auto-isolement des hôtes (ils s’arrêtent). Les hôtes peuvent ne pas redémarrer correctement et peuvent nécessiter la commande host-emergency-ha-disable pour récupérer.

Sélectionnez l’hôte que vous souhaitez désigner comme coordinateur de pool. Le coordinateur de pool appartient par défaut à un pool sans nom. Pour créer un pool de ressources avec l’interface de ligne de commande (CLI), renommez le pool sans nom existant :

xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->

Créez la liaison de carte réseau (NIC bond) comme décrit dans Créer une liaison de carte réseau.

Ouvrez une console sur un hôte que vous souhaitez joindre au pool et exécutez la commande :

xe pool-join master-address=host1 master-username=root master-password=password
<!--NeedCopy-->

Les informations réseau et de liaison sont automatiquement répliquées sur le nouvel hôte. L’interface de gestion est automatiquement déplacée de la carte réseau (NIC) de l’hôte où elle était initialement configurée vers le PIF lié. C’est-à-dire que l’interface de gestion est maintenant absorbée dans la liaison afin que l’ensemble de la liaison fonctionne comme interface de gestion.

Utilisez la commande host-list pour trouver l’UUID de l’hôte en cours de configuration :

xe host-list
<!--NeedCopy-->

Avertissement :

N’essayez pas de créer des liaisons réseau lorsque la haute disponibilité est activée. Le processus de création de liaison perturbe le battement de cœur de la haute disponibilité en cours et provoque l’auto-isolement des hôtes (ils s’arrêtent). Les hôtes peuvent ne pas redémarrer correctement et vous devrez peut-être exécuter la commande host-emergency-ha-disable pour récupérer.

Configurer une carte réseau de stockage dédiée

Vous pouvez utiliser XenCenter ou l’interface de ligne de commande xe pour attribuer une adresse IP à une carte réseau et la dédier à une fonction spécifique, telle que le trafic de stockage. Lorsque vous configurez une carte réseau avec une adresse IP, vous le faites en créant une interface secondaire. (La carte réseau compatible IP utilisée par XenServer pour la gestion est appelée interface de gestion.)

Lorsque vous souhaitez dédier une interface secondaire à un usage spécifique, assurez-vous que la configuration réseau appropriée est en place. Cela garantit que la carte réseau est utilisée uniquement pour le trafic souhaité. Pour dédier une carte réseau au trafic de stockage, configurez la carte réseau, la cible de stockage, le commutateur et le VLAN de manière à ce que la cible ne soit accessible que via la carte réseau attribuée. Si votre configuration physique et IP ne limite pas le trafic envoyé via la carte réseau de stockage, vous pouvez envoyer du trafic, tel que le trafic de gestion, via l’interface secondaire.

Lorsque vous créez une nouvelle interface secondaire pour le trafic de stockage, vous devez lui attribuer une adresse IP qui est :

Sur le même sous-réseau que le contrôleur de stockage, le cas échéant, et
Pas sur le même sous-réseau que toute autre interface secondaire ou l’interface de gestion.

Lorsque vous configurez des interfaces secondaires, chaque interface secondaire doit se trouver sur un sous-réseau distinct. Par exemple, si vous souhaitez configurer deux interfaces secondaires supplémentaires pour le stockage, vous avez besoin d’adresses IP sur trois sous-réseaux différents – un sous-réseau pour l’interface de gestion, un sous-réseau pour l’interface secondaire 1 et un sous-réseau pour l’interface secondaire 2.

Remarque :

Lorsque vous sélectionnez une carte réseau à configurer comme interface secondaire pour une utilisation avec des SR iSCSI ou NFS, assurez-vous que la carte réseau dédiée utilise un sous-réseau IP distinct qui n’est pas routable depuis l’interface de gestion. Si cela n’est pas appliqué, le trafic de stockage peut être dirigé via l’interface de gestion principale après un redémarrage de l’hôte, en raison de l’ordre d’initialisation des interfaces réseau.

Assurez-vous que le PIF se trouve sur un sous-réseau distinct, ou que le routage est configuré pour s’adapter à votre topologie réseau afin de forcer le trafic souhaité sur le PIF sélectionné.

Configurez une configuration IP pour le PIF, en ajoutant les valeurs appropriées pour le paramètre de mode. Si vous utilisez l’adressage IP statique, ajoutez les paramètres IP, masque de sous-réseau, passerelle et DNS :

xe pif-reconfigure-ip mode=DHCP | Static uuid=pif-uuid
<!--NeedCopy-->

Définissez le paramètre disallow-unplug du PIF sur true :

xe pif-param-set disallow-unplug=true uuid=pif-uuid
<!--NeedCopy-->

xe pif-param-set other-config:management_purpose="Storage" uuid=pif-uuid
<!--NeedCopy-->

Si vous souhaitez utiliser une interface secondaire pour le stockage qui peut également être routée depuis l’interface de gestion (en gardant à l’esprit que cette configuration n’est pas la meilleure pratique), vous avez deux options :

Après un redémarrage de l’hôte, assurez-vous que l’interface secondaire est correctement configurée. Utilisez les commandes xe pbd-unplug et xe pbd-plug pour réinitialiser les connexions de stockage sur l’hôte. Cette commande redémarre la connexion de stockage et la route via l’interface correcte.
Alternativement, vous pouvez utiliser xe pif-forget pour supprimer l’interface de la base de données XenServer et la configurer manuellement dans le domaine de contrôle. xe pif-forget est une option avancée et nécessite que vous soyez familiarisé avec la configuration manuelle du réseau Linux.

Utiliser des cartes réseau compatibles SR-IOV

La virtualisation d’E/S à racine unique (SR-IOV) est une technologie de virtualisation qui permet à un seul périphérique PCI d’apparaître comme plusieurs périphériques PCI sur le système physique. Le périphérique physique réel est appelé fonction physique (PF) tandis que les autres sont appelés fonctions virtuelles (VF). L’hyperviseur peut attribuer une ou plusieurs VF à une machine virtuelle (VM) : l’invité peut alors utiliser le périphérique comme s’il lui était directement attribué.

L’attribution d’une ou plusieurs VF de carte réseau à une machine virtuelle permet à son trafic réseau de contourner le commutateur virtuel. Une fois configurée, chaque machine virtuelle se comporte comme si elle utilisait directement la carte réseau, ce qui réduit la surcharge de traitement et améliore les performances.

Avantages du SR-IOV

Une VF SR-IOV offre de meilleures performances qu’une VIF. Elle peut assurer la ségrégation matérielle entre le trafic de différentes machines virtuelles via la même carte réseau (en contournant la pile réseau XenServer).

Grâce à cette fonctionnalité, vous pouvez :

Activer le SR-IOV sur les cartes réseau qui le prennent en charge.
Désactiver le SR-IOV sur les cartes réseau qui le prennent en charge.
Gérer les VF SR-IOV comme un pool de ressources VF.
Attribuer des VF SR-IOV à une machine virtuelle.
Configurer les VF SR-IOV (par exemple, adresse MAC, VLAN, débit).
Exécuter des tests pour confirmer si le SR-IOV est pris en charge dans le cadre du Kit de Certification Automatisé.

Configuration du système

Configurez correctement la plateforme matérielle pour prendre en charge le SR-IOV. Les technologies suivantes sont requises :

Virtualisation I/O MMU (AMD-Vi et Intel VT-d)
Interprétation alternative de l’ID de routage (ARI)
Services de traduction d’adresses (ATS)
Services de contrôle d’accès (ACS)

Consultez la documentation fournie avec votre système pour savoir comment configurer le micrologiciel du système afin d’activer les technologies mentionnées.

Activer un réseau SR-IOV sur une carte réseau

Dans XenCenter, utilisez l’assistant Nouveau réseau dans l’onglet Mise en réseau pour créer et activer un réseau SR-IOV sur une carte réseau.

Attribuer un réseau SR-IOV à l’interface virtuelle (niveau VM)

Dans XenCenter, au niveau de la VM, utilisez l’assistant Ajouter une interface virtuelle dans l’onglet Mise en réseau pour ajouter un réseau compatible SR-IOV en tant qu’interface virtuelle pour cette VM. Pour plus d’informations, consultez Ajouter un nouveau réseau.

Cartes réseau et invités pris en charge

Pour obtenir la liste des plates-formes matérielles et des cartes réseau prises en charge, consultez la Liste de compatibilité matérielle. Consultez la documentation fournie par le fournisseur pour un invité particulier afin de déterminer s’il prend en charge SR-IOV.

Limitations

Pour certaines cartes réseau utilisant des pilotes hérités (par exemple, la famille Intel I350), l’hôte doit être redémarré pour activer ou désactiver SR-IOV sur ces périphériques.
Un réseau SR-IOV au niveau du pool ayant différents types de cartes réseau n’est pas pris en charge.
Une VF SR-IOV et une VIF normale de la même carte réseau peuvent ne pas être en mesure de communiquer entre elles en raison des limitations matérielles de la carte réseau. Pour permettre à ces VM de communiquer, assurez-vous que la communication utilise le modèle VF vers VF ou VIF vers VIF, et non VF vers VIF.
Les paramètres de qualité de service pour certains VF SR-IOV ne prennent pas effet car ils ne prennent pas en charge la limitation du débit réseau.
L’exécution de la migration en direct, de la suspension et du point de contrôle n’est pas prise en charge sur les machines virtuelles utilisant un VF SR-IOV.
Les VF SR-IOV ne prennent pas en charge le branchement à chaud.
Les VF SR-IOV ne prennent pas en charge le démarrage réseau.
Pour certaines cartes réseau avec des pilotes de carte réseau hérités, un redémarrage peut être nécessaire même après le redémarrage de l’hôte, ce qui indique que la carte réseau n’est pas en mesure d’activer SR-IOV.
Si votre machine virtuelle possède un VF SR-IOV, les fonctions nécessitant la migration en direct ne sont pas possibles. Cela est dû au fait que la machine virtuelle est directement liée au VF de la carte réseau physique compatible SR-IOV.
SR-IOV peut être utilisé dans un environnement qui utilise la haute disponibilité. Cependant, SR-IOV n’est pas pris en compte dans la planification de la capacité. Les machines virtuelles auxquelles des VF SR-IOV sont attribués sont redémarrées au mieux de leurs capacités lorsqu’il y a un hôte dans le pool qui dispose des ressources appropriées. Ces ressources incluent SR-IOV activé sur le bon réseau et un VF libre.
Les VF SR-IOV ne sont pas pris en charge avec le PVS-Accelerator.

Configurer les VF SR-IOV pour les pilotes hérités

Généralement, le nombre maximal de VF qu’une carte réseau peut prendre en charge peut être déterminé automatiquement. Pour les cartes réseau utilisant des pilotes hérités (par exemple, la famille Intel I350), la limite est définie dans le fichier de configuration du module de pilote. La limite peut devoir être ajustée manuellement. Pour la définir au maximum, ouvrez le fichier à l’aide d’un éditeur et modifiez la ligne commençant par :

## VFs-maxvfs-by-user:
<!--NeedCopy-->

Par exemple, pour définir le nombre maximal de VF à 4 pour le pilote igb, modifiez /etc/modprobe.d/igb.conf pour qu’il lise :

## VFs-param: max_vfs
## VFs-maxvfs-by-default: 7
## VFs-maxvfs-by-user: 4
options igb max_vfs=0
<!--NeedCopy-->

Remarques :

La valeur doit être inférieure ou égale à la valeur de la ligne VFs-maxvfs-by-default.

Ne modifiez aucune autre ligne dans ces fichiers.

Apportez les modifications avant d’activer SR-IOV.

CLI

Voir commandes SR-IOV pour les instructions CLI sur la création, la suppression, l’affichage des réseaux SR-IOV et l’affectation d’un VF SR-IOV à une VM.

Contrôler le débit des données sortantes (QoS)

Pour limiter la quantité de données sortantes qu’une VM peut envoyer par seconde, définissez une valeur optionnelle de Qualité de Service (QoS) sur les interfaces virtuelles de VM (VIF). Ce paramètre vous permet de spécifier un débit de transmission maximal pour les paquets sortants en kilooctets par seconde.

La valeur de Qualité de Service limite le débit de transmission depuis la VM. Le paramètre de Qualité de Service ne limite pas la quantité de données que la VM peut recevoir. Si une telle limite est souhaitée, nous recommandons de limiter le débit des paquets entrants plus haut dans le réseau (par exemple, au niveau du commutateur).

Selon la pile réseau configurée dans le pool, vous pouvez définir la valeur de Qualité de Service sur les interfaces virtuelles de VM (VIF) à l’un des deux endroits suivants. Vous pouvez définir cette valeur soit en utilisant l’interface CLI xe, soit dans XenCenter.

XenCenter Vous pouvez définir la valeur limite du débit de transmission de la Qualité de Service dans la boîte de dialogue des propriétés de l’interface virtuelle.
Commandes xe Vous pouvez définir le débit de transmission de la Qualité de Service via l’interface CLI en utilisant les commandes de la section suivante.

Exemple de commande CLI pour la QoS

Pour limiter un VIF à un débit de transmission maximal de 100 kilooctets par seconde en utilisant l’interface CLI, utilisez la commande vif-param-set :

xe vif-param-set uuid=vif_uuid qos_algorithm_type=ratelimit
xe vif-param-set uuid=vif_uuid qos_algorithm_params:kbps=100
<!--NeedCopy-->

Remarque :

Le paramètre kbps désigne des kilooctets par seconde (ko/s), et non des kilobits par seconde (kbps).

Modifier les options de configuration réseau

Cette section explique comment modifier la configuration réseau de votre hôte XenServer. Elle comprend :

Modification du nom d’hôte (c’est-à-dire le nom du système de noms de domaine (DNS))
Ajout ou suppression de serveurs DNS
Modification des adresses IP
Modification de la carte réseau utilisée comme interface de gestion
Ajout d’une nouvelle carte réseau physique au serveur
Ajout d’un objectif à un réseau
Activation du filtrage ARP (verrouillage de port de commutateur)

Nom d’hôte

Le nom d’hôte du système, également appelé nom de domaine ou nom DNS, est défini dans la base de données de l’ensemble du pool et est modifié à l’aide de la commande CLI xe host-set-hostname-live comme suit :

xe host-set-hostname-live host-uuid=host_uuid host-name=host-name
<!--NeedCopy-->

Le nom d’hôte du domaine de contrôle sous-jacent change dynamiquement pour refléter le nouveau nom d’hôte.

Serveurs DNS

Pour ajouter ou supprimer des serveurs DNS dans la configuration d’adressage IP de l’hôte XenServer, utilisez la commande pif-reconfigure-ip. Par exemple, pour une PIF avec une adresse IP statique :

xe pif-reconfigure-ip uuid=pif_uuid mode=static DNS=new_dns_ip IP=IP netmask=netmask
<!--NeedCopy-->

Modifier la configuration d’adresse IP pour un hôte autonome

Vous pouvez utiliser l’interface de ligne de commande xe pour modifier la configuration de l’interface réseau. Ne modifiez pas directement les scripts de configuration réseau sous-jacents.

Pour modifier la configuration d’adresse IP d’une PIF, utilisez la commande CLI pif-reconfigure-ip. Consultez pif-reconfigure-ip pour plus de détails sur les paramètres de la commande pif-reconfigure-ip. Consultez la section suivante pour plus d’informations sur la modification des adresses IP d’hôte dans les pools de ressources.

Modifier la configuration d’adresse IP dans les pools de ressources

Les hôtes XenServer des pools de ressources ont une seule adresse IP de gestion utilisée pour la gestion et la communication vers et depuis les autres hôtes du pool. Les étapes requises pour modifier l’adresse IP de l’interface de gestion d’un hôte sont différentes pour le coordinateur de pool et les autres hôtes.

Remarque :

Vous devez être prudent lorsque vous modifiez l’adresse IP d’un hôte et d’autres paramètres réseau. Selon la topologie du réseau et la modification effectuée, les connexions au stockage réseau peuvent être perdues. Dans ce cas, le stockage doit être reconnecté à l’aide de la fonction Réparer le stockage dans XenCenter, ou en utilisant la commande CLI pbd-plug. Pour cette raison, nous vous recommandons de migrer les machines virtuelles hors de l’hôte avant de modifier sa configuration IP.

Utilisez la commande CLI pif-reconfigure-ip pour définir l’adresse IP comme souhaité. Consultez pif-reconfigure-ip pour plus de détails sur les paramètres de la commande pif-reconfigure-ip :

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
<!--NeedCopy-->

Utilisez la commande CLI host-list pour confirmer que l’hôte membre s’est reconnecté avec succès au coordinateur de pool en vérifiant que tous les autres hôtes XenServer du pool sont visibles :

xe host-list
<!--NeedCopy-->

La modification de l’adresse IP de l’hôte XenServer coordinateur de pool nécessite des étapes supplémentaires. En effet, chaque membre du pool utilise l’adresse IP annoncée du coordinateur de pool pour la communication. Les membres du pool ne savent pas comment contacter le coordinateur de pool lorsque son adresse IP change.

Dans la mesure du possible, utilisez une adresse IP dédiée qui ne risque pas de changer pendant la durée de vie du pool pour les coordinateurs de pool.

Utilisez la commande CLI pif-reconfigure-ip pour définir l’adresse IP comme souhaité :

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
<!--NeedCopy-->

Lorsque l’adresse IP du coordinateur de pool change, tous les hôtes membres passent en mode d’urgence s’ils ne parviennent pas à contacter le coordinateur de pool.

Sur le coordinateur de pool, utilisez la commande pool-recover-slaves pour forcer le coordinateur de pool à contacter chaque membre du pool et à les informer de la nouvelle adresse IP du coordinateur de pool :

xe pool-recover-slaves
<!--NeedCopy-->

Interface de gestion

Lorsque vous installez XenServer sur un hôte, l’une de ses cartes réseau est désignée comme interface de gestion : la carte réseau utilisée pour le trafic de gestion XenServer. L’interface de gestion est utilisée pour les connexions XenCenter à l’hôte (par exemple, Citrix Virtual Apps and Desktops™) et pour la communication d’hôte à hôte.

Utilisez la commande pif-list pour déterminer quel PIF correspond à la carte réseau à utiliser comme interface de gestion. L’UUID de chaque PIF est renvoyé.

xe pif-list
<!--NeedCopy-->

Utilisez la commande pif-param-list pour vérifier la configuration d’adressage IP du PIF utilisé pour l’interface de gestion. Si nécessaire, utilisez la commande pif-reconfigure-ip pour configurer l’adressage IP du PIF à utiliser.

xe pif-param-list uuid=pif_uuid
<!--NeedCopy-->

Utilisez la commande CLI host-management-reconfigure pour modifier le PIF utilisé pour l’interface de gestion. Si cet hôte fait partie d’un pool de ressources, cette commande doit être exécutée sur la console de l’hôte membre :

xe host-management-reconfigure pif-uuid=pif_uuid
<!--NeedCopy-->

Utilisez la commande network-list pour déterminer quelle PIF correspond à la carte réseau à utiliser comme interface de gestion pour tous les hôtes du pool. L’UUID du réseau à l’échelle du pool est renvoyé.

xe network-list
<!--NeedCopy-->

Utilisez la commande network-param-list pour récupérer les UUID des PIF de tous les hôtes du pool. Utilisez la commande pif-param-list pour vérifier la configuration d’adressage IP de la PIF pour l’interface de gestion. Si nécessaire, utilisez la commande pif-reconfigure-ip pour configurer l’adressage IP de la PIF à utiliser.

xe pif-param-list uuid=pif_uuid
<!--NeedCopy-->

Utilisez la commande CLI pool-management-reconfigure pour modifier la PIF utilisée pour l’interface de gestion répertoriée dans la liste Réseaux.

xe pool-management-reconfigure network-uuid=network_uuid
<!--NeedCopy-->

Restreindre l’utilisation du port 80

Vous pouvez utiliser HTTPS sur le port 443 ou HTTP sur le port 80 pour communiquer avec XenServer. Pour des raisons de sécurité, le port 80 est fermé par défaut pour les nouvelles installations. Les mises à niveau conservent les paramètres de port existants.

Pour ouvrir ou fermer le port 80, consultez la commande CLI xe https-only ou Modifier les propriétés du pool dans la documentation XenCenter.

Désactiver l’accès de gestion

Pour désactiver entièrement l’accès à distance à la console de gestion, utilisez la commande CLI host-management-disable.

Avertissement :

Lorsque l’interface de gestion est désactivée, vous devez vous connecter à la console de l’hôte physique pour effectuer les tâches de gestion. Les interfaces externes telles que XenCenter ne fonctionnent pas lorsque l’interface de gestion est désactivée.

Ajouter une nouvelle carte réseau physique

Installez une nouvelle carte réseau physique sur votre hôte XenServer de la manière habituelle.
Redémarrez votre hôte XenServer.
Répertoriez toutes les cartes réseau physiques pour cet hôte XenServer à l’aide de la commande suivante :
```
xe pif-list host-uuid=<host_uuid>
```
Si vous ne voyez pas la carte réseau supplémentaire, recherchez de nouvelles interfaces physiques à l’aide de la commande suivante :
```
xe pif-scan host-uuid=<host_uuid>
```
Cette commande crée un nouvel objet PIF pour la nouvelle carte réseau.
Listez à nouveau les cartes réseau physiques sur l’hôte XenServer pour vérifier que la nouvelle carte réseau est visible :
```
xe pif-list host-uuid=<host_uuid>
```
Le nouveau PIF est initialement répertorié comme déconnecté (currently-attached ( RO): false). Pour l’activer, utilisez la commande suivante :
```
xe pif-plug uuid=<uuid_of_pif>
```

Vous pouvez également utiliser XenCenter pour rechercher de nouvelles cartes réseau. Pour plus d’informations, consultez Configuration des cartes réseau dans la documentation XenCenter.

Supprimer une carte réseau physique

Avant de retirer la carte réseau, assurez-vous de connaître l’UUID du PIF correspondant. Retirez la carte réseau physique de votre hôte XenServer de la manière habituelle. Après avoir redémarré l’hôte, exécutez la commande xe CLI pif-forget uuid=<UUID> pour détruire l’objet PIF.

Ajouter un objectif à un réseau

L’objectif du réseau peut être utilisé pour ajouter des fonctionnalités supplémentaires à un réseau. Par exemple, la possibilité d’utiliser le réseau pour établir des connexions NBD.

Pour ajouter un objectif de réseau, utilisez la commande xe network-param-add :

xe network-param-add param-name=purpose param-key=purpose uuid=network-uuid
<!--NeedCopy-->

Pour supprimer un objectif de réseau, utilisez la commande xe network-param-remove :

xe network-param-remove param-name=purpose param-key=purpose uuid=network-uuid
<!--NeedCopy-->

Actuellement, les valeurs disponibles pour l’objectif du réseau sont nbd et insecure_nbd. Pour plus d’informations, consultez le Guide de suivi des blocs modifiés de XenServer.

Utiliser le verrouillage de port de commutateur

La fonction de verrouillage de port de commutateur de XenServer vous permet de contrôler le trafic envoyé par des machines virtuelles inconnues, non fiables ou potentiellement hostiles en limitant leur capacité à prétendre qu’elles ont une adresse MAC ou IP qui ne leur a pas été attribuée. Vous pouvez utiliser les commandes de verrouillage de port pour bloquer tout le trafic sur un réseau par défaut ou définir des adresses IP spécifiques à partir desquelles une machine virtuelle individuelle est autorisée à envoyer du trafic.

L’utilisation du verrouillage de port de commutateur vous permet de simplifier votre configuration réseau en permettant à tous vos locataires ou invités d’utiliser le même réseau de couche 2.

L’une des fonctions les plus importantes des commandes de verrouillage de port est qu’elles peuvent restreindre le trafic qu’un invité non fiable envoie. Cela limite la capacité de l’invité à prétendre qu’il possède une adresse MAC ou IP qu’il n’a pas réellement. Plus précisément, vous pouvez utiliser ces commandes pour empêcher un invité de :

Revendiquer une adresse IP ou MAC autre que celles que l’administrateur XenServer a spécifiées comme utilisables.
Intercepter, usurper ou perturber le trafic d’autres machines virtuelles.

Exigences

Lorsque vous activez le contrôle d’accès basé sur les rôles (RBAC) dans votre environnement, l’utilisateur configurant le verrouillage de port de commutateur doit être connecté avec un compte ayant au moins un rôle d’opérateur de pool ou d’administrateur de pool. Lorsque le RBAC n’est pas activé dans votre environnement, l’utilisateur doit être connecté avec le compte root du coordinateur de pool.
Lorsque vous exécutez les commandes de verrouillage de port de commutateur, les réseaux peuvent être en ligne ou hors ligne.
Dans les invités Windows, l’icône Réseau déconnecté n’apparaît que lorsque les outils XenServer VM sont installés dans l’invité.

Remarques

Sans aucune configuration de verrouillage de port de commutateur, les VIF sont définis sur “network_default” et les réseaux sont définis sur “unlocked”.

La configuration du verrouillage de port de commutateur n’est pas prise en charge lorsque des contrôleurs tiers sont utilisés dans l’environnement.

Le verrouillage de port de commutateur n’empêche pas les locataires du cloud de :

Effectuer une attaque au niveau IP sur un autre locataire/utilisateur. Cependant, le verrouillage de port de commutateur les empêche d’effectuer l’attaque au niveau IP s’ils tentent d’utiliser les moyens suivants pour ce faire et que le verrouillage de port de commutateur est configuré : a) usurper l’identité d’un autre locataire dans le cloud ou d’un utilisateur ou b) initier une interception de trafic destiné à un autre utilisateur.
Épuiser les ressources réseau.
Recevoir du trafic destiné à d’autres machines virtuelles via les comportements normaux de diffusion de commutateur (pour les adresses MAC de diffusion ou les adresses MAC de destination inconnues).

De même, le verrouillage de port de commutateur ne restreint pas l’endroit où une machine virtuelle peut envoyer du trafic.

Notes d’implémentation

Vous pouvez implémenter la fonctionnalité de verrouillage de port de commutateur soit en utilisant la ligne de commande, soit l’API XenServer. Cependant, dans les environnements de grande taille où l’automatisation est une préoccupation majeure, la méthode d’implémentation la plus courante pourrait être l’utilisation de l’API.

Exemples

Cette section fournit des exemples de la manière dont le verrouillage de port de commutateur peut prévenir certains types d’attaques. Dans ces exemples, la VM-c est une machine virtuelle qu’un locataire hostile (Locataire C) loue et utilise pour des attaques. Les VM-a et VM-b sont des machines virtuelles louées par des locataires non-attaquants.

Exemple 1 : Comment le verrouillage de port de commutateur peut prévenir l’usurpation d’ARP :

L’usurpation d’ARP est utilisée pour désigner les tentatives d’un attaquant d’associer son adresse MAC à l’adresse IP d’un autre nœud. L’usurpation d’ARP peut potentiellement entraîner l’envoi du trafic du nœud à l’attaquant à la place. Pour atteindre cet objectif, l’attaquant envoie de faux messages ARP (usurpés) à un réseau local Ethernet.

Scénario :

La machine virtuelle A (VM-a) veut envoyer du trafic IP de la VM-a à la machine virtuelle B (VM-b) en l’adressant à l’adresse IP de la VM-b. Le propriétaire de la machine virtuelle C veut utiliser l’usurpation d’ARP pour faire croire que sa VM, la VM-c, est en fait la VM-b.

La VM-c envoie un flux spéculatif de réponses ARP à la VM-a. Les réponses ARP affirment que l’adresse MAC dans la réponse (c_MAC) est associée à l’adresse IP, b_IP.

Résultat : Étant donné que l’administrateur a activé le verrouillage de port de commutateur, ces paquets sont tous abandonnés car l’activation du verrouillage de port de commutateur empêche l’usurpation d’identité.
La VM-b envoie une réponse ARP à la VM-a, affirmant que l’adresse MAC dans la réponse (b_MAC) est associée à l’adresse IP, b_IP.

Résultat : La VM-a reçoit la réponse ARP de la VM-b.

Exemple 2 : Prévention de l’usurpation d’IP :

L’usurpation d’adresse IP est un processus qui dissimule l’identité des paquets en créant des paquets de protocole Internet (IP) avec une adresse IP source falsifiée.

Scénario :

Le locataire C tente d’effectuer une attaque par déni de service en utilisant son hôte, Hôte-C, sur un système distant pour dissimuler son identité.

Tentative 1 :

Le locataire C définit l’adresse IP et l’adresse MAC de l’hôte C sur les adresses IP et MAC de la VM-a (a_IP et a_MAC). Le locataire C demande à l’hôte C d’envoyer du trafic IP à un système distant.

Résultat : Les paquets de l’hôte C sont abandonnés. Ceci est dû au fait que l’administrateur a activé le verrouillage des ports de commutateur. Les paquets de l’hôte C sont abandonnés car l’activation du verrouillage des ports de commutateur empêche l’usurpation d’identité.

Tentative 2 :

Le locataire C définit l’adresse IP de l’hôte C sur l’adresse IP de la VM-a (a_IP) et conserve son adresse MAC d’origine, c_MAC.

Le locataire C demande à l’hôte C d’envoyer du trafic IP à un système distant.

Résultat : Les paquets de l’hôte C sont abandonnés. Ceci est dû au fait que l’administrateur a activé le verrouillage des ports de commutateur, ce qui empêche l’usurpation d’identité.

Exemple 3 : Hébergement Web :

Scénario :

Alice est une administratrice d’infrastructure.

L’un de ses locataires, le locataire B, héberge plusieurs sites Web depuis sa VM, VM-b. Chaque site Web nécessite une adresse IP distincte hébergée sur la même interface réseau virtuelle (VIF).

Alice reconfigure la VIF de l’hôte B pour qu’elle soit verrouillée à une seule adresse MAC mais à plusieurs adresses IP.

Fonctionnement du verrouillage des ports de commutateur

La fonctionnalité de verrouillage des ports de commutateur vous permet de contrôler le filtrage des paquets à un ou plusieurs des deux niveaux suivants :

Niveau VIF. Les paramètres que vous configurez sur la VIF déterminent la manière dont les paquets sont filtrés. Vous pouvez configurer la VIF pour empêcher la VM d’envoyer du trafic, restreindre la VIF afin qu’elle ne puisse envoyer du trafic qu’en utilisant son adresse IP attribuée, ou autoriser la VM à envoyer du trafic à n’importe quelle adresse IP sur le réseau connecté à la VIF.
Niveau du réseau. Le réseau XenServer détermine comment les paquets sont filtrés. Lorsque le mode de verrouillage d’une VIF est défini sur network_default, il se réfère au paramètre de verrouillage au niveau du réseau pour déterminer quel trafic autoriser.

États du mode de verrouillage des VIF

La fonctionnalité de verrouillage de port de commutateur XenServer fournit un mode de verrouillage qui vous permet de configurer les VIF dans quatre états différents. Ces états s’appliquent uniquement lorsque la VIF est connectée à une machine virtuelle en cours d’exécution.

Network_default. Lorsque l’état de la VIF est défini sur network_default, XenServer utilise le paramètre default-locking-mode du réseau pour déterminer si et comment filtrer les paquets transitant par la VIF. Le comportement varie selon que le réseau associé a le paramètre de mode de verrouillage par défaut du réseau défini sur désactivé ou déverrouillé :

-default-locking-mode=disabled, XenServer applique une règle de filtrage de sorte que la VIF supprime tout le trafic.

-default-locking-mode=unlocked, XenServer supprime toutes les règles de filtrage associées à la VIF. Par défaut, le paramètre de mode de verrouillage par défaut est défini sur unlocked.

Pour plus d’informations sur le paramètre default-locking-mode, consultez Commandes réseau.

Le mode de verrouillage par défaut du réseau n’a aucun effet sur les VIF attachées dont l’état de verrouillage est différent de network_default.

Remarque :

Vous ne pouvez pas modifier le default-locking-mode d’un réseau auquel des VIF actives sont attachées.
Verrouillé. XenServer applique des règles de filtrage de sorte que seul le trafic envoyé vers/depuis les adresses MAC et IP spécifiées est autorisé à être envoyé via la VIF. Dans ce mode, si aucune adresse IP n’est spécifiée, la VM ne peut envoyer aucun trafic via cette VIF, sur ce réseau.

Pour spécifier les adresses IP à partir desquelles la VIF accepte le trafic, utilisez les adresses IP IPv4 ou IPv6 en utilisant les paramètres ipv4_allowed ou ipv6_allowed.
Déverrouillé. Tout le trafic réseau peut transiter par la VIF. Autrement dit, aucun filtre n’est appliqué au trafic entrant ou sortant de la VIF.
Désactivé. Aucun trafic n’est autorisé à transiter par la VIF. (Autrement dit, XenServer applique une règle de filtrage de sorte que la VIF supprime tout le trafic.)

Configurer le verrouillage des ports de commutateur

Cette section propose trois procédures différentes :

Restreindre les VIF à l’utilisation d’une adresse IP spécifique
Ajouter une adresse IP à une liste restreinte existante. Par exemple, pour ajouter une adresse IP à un VIF lorsque la machine virtuelle est en cours d’exécution et connectée au réseau (par exemple, si vous mettez temporairement un réseau hors ligne).
Supprimer une adresse IP d’une liste restreinte existante

Si le mode de verrouillage d’un VIF est défini sur locked, il ne peut utiliser que les adresses spécifiées dans les paramètres ipv4-allowed ou ipv6-allowed.

Étant donné que, dans certains cas relativement rares, les VIF peuvent avoir plus d’une adresse IP, il est possible de spécifier plusieurs adresses IP pour un VIF.

Vous pouvez effectuer ces procédures avant ou après le branchement du VIF (ou le démarrage de la machine virtuelle).

Changez le mode de verrouillage par défaut en mode verrouillé, s’il n’utilise pas déjà ce mode, en exécutant la commande suivante :

xe vif-param-set uuid=vif-uuid locking-mode=locked
<!--NeedCopy-->

vif-uuid représente l’UUID du VIF que vous souhaitez autoriser à envoyer du trafic. Pour obtenir l’UUID, exécutez la commande xe vif-list sur l’hôte. vm-uuid Indique la machine virtuelle pour laquelle les informations apparaissent. L’ID de périphérique indique le numéro de périphérique du VIF.

Exécutez la commande vif-param-set pour spécifier les adresses IP à partir desquelles la machine virtuelle peut envoyer du trafic. Effectuez une ou plusieurs des opérations suivantes :

Spécifiez une ou plusieurs destinations d’adresses IP IPv4. Par exemple :

 xe vif-param-set uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
 <!--NeedCopy-->

Spécifiez une ou plusieurs destinations d’adresses IP IPv6. Par exemple :

 xe vif-param-set uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
 <!--NeedCopy-->

Vous pouvez spécifier plusieurs adresses IP en les séparant par une virgule, comme indiqué dans l’exemple précédent.

Après avoir effectué la procédure pour restreindre un VIF à l’utilisation d’une adresse IP spécifique, vous pouvez ajouter une ou plusieurs adresses IP que le VIF peut utiliser.

Exécutez la commande vif-param-add pour ajouter les adresses IP à la liste existante. Effectuez une ou plusieurs des opérations suivantes :

Spécifiez l’adresse IP IPv4. Par exemple :

 xe vif-param-add uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
 <!--NeedCopy-->

Spécifiez l’adresse IP IPv6. Par exemple :

 xe vif-param-add uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
 <!--NeedCopy-->

Si vous limitez une VIF à l’utilisation de deux adresses IP ou plus, vous pouvez supprimer l’une de ces adresses IP de la liste.

Exécutez la commande vif-param-remove pour supprimer les adresses IP de la liste existante. Effectuez une ou plusieurs des opérations suivantes :

Spécifiez l’adresse IP IPv4 à supprimer. Par exemple :

 xe vif-param-remove uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
 <!--NeedCopy-->

Spécifiez l’adresse IP IPv6 à supprimer. Par exemple :

 xe vif-param-remove uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
 <!--NeedCopy-->

Empêcher une machine virtuelle d’envoyer ou de recevoir du trafic depuis un réseau spécifique

La procédure suivante empêche une machine virtuelle de communiquer via une VIF spécifique. Comme une VIF se connecte à un réseau XenServer spécifique, vous pouvez utiliser cette procédure pour empêcher une machine virtuelle d’envoyer ou de recevoir du trafic depuis un réseau spécifique. Cela offre un niveau de contrôle plus granulaire que la désactivation d’un réseau entier.

Si vous utilisez la commande CLI, vous n’avez pas besoin de débrancher la VIF pour définir son mode de verrouillage. La commande modifie les règles de filtrage pendant que la VIF est en cours d’exécution. Dans ce cas, la connexion réseau semble toujours présente, mais la VIF supprime tous les paquets que la VM tente d’envoyer.

Conseil :

Pour trouver l’UUID d’une VIF, exécutez la commande xe vif-list sur l’hôte. L’ID du périphérique indique le numéro de périphérique de la VIF.

Pour empêcher une VIF de recevoir du trafic, désactivez la VIF connectée au réseau à partir duquel vous souhaitez empêcher la VM de recevoir du trafic :

xe vif-param-set uuid=vif-uuid locking-mode=disabled
<!--NeedCopy-->

Vous pouvez également désactiver la VIF dans XenCenter en sélectionnant l’interface réseau virtuelle dans l’onglet Réseau de la VM et en cliquant sur Désactiver.

Supprimer la restriction d’une VIF à une adresse IP

Pour revenir à l’état par défaut (original) du mode de verrouillage, utilisez la procédure suivante. Par défaut, lorsque vous créez un VIF, XenServer le configure de manière à ce qu’il ne soit pas restreint à l’utilisation d’une adresse IP spécifique.

Pour ramener un VIF à un état déverrouillé, changez le mode de verrouillage par défaut du VIF en « déverrouillé ». S’il n’utilise pas déjà ce mode, exécutez la commande suivante :

xe vif-param-set uuid=vif_uuid locking-mode=unlocked
<!--NeedCopy-->

Simplifier la configuration du mode de verrouillage VIF dans le Cloud

Plutôt que d’exécuter les commandes de mode de verrouillage VIF pour chaque VIF, vous pouvez vous assurer que tous les VIF sont désactivés par défaut. Pour ce faire, vous devez modifier le filtrage des paquets au niveau du réseau. La modification du filtrage des paquets amène le réseau XenServer à déterminer comment les paquets sont filtrés, comme décrit dans la section précédente Fonctionnement du verrouillage de port de commutateur.

Plus précisément, le paramètre default-locking-mode d’un réseau détermine le comportement des nouveaux VIF avec les paramètres par défaut. Chaque fois que le locking-mode d’un VIF est défini sur default, le VIF se réfère au mode de verrouillage du réseau (default-locking-mode) pour déterminer si et comment filtrer les paquets transitant par le VIF :

Déverrouillé. Lorsque le paramètre default-locking-mode du réseau est défini sur unlocked, XenServer permet à la VM d’envoyer du trafic à n’importe quelle adresse IP sur le réseau auquel le VIF est connecté.
Désactivé. Lorsque le paramètre default-locking-mode est défini sur disabled, XenServer applique une règle de filtrage de sorte que le VIF supprime tout le trafic.

Par défaut, le default-locking-mode de tous les réseaux créés dans XenCenter et utilisant la CLI est défini sur unlocked.

En définissant le mode de verrouillage du VIF sur sa valeur par défaut (network_default), vous pouvez créer une configuration par défaut de base (au niveau du réseau) pour tous les VIF nouvellement créés qui se connectent à un réseau spécifique.

Cette illustration montre comment, lorsqu’un locking-mode de VIF est défini sur son paramètre par défaut (network_default), le VIF utilise le default-locking-mode du réseau pour déterminer son comportement.

Cette illustration montre comment un VIF, lorsqu'il est configuré avec son paramètre par défaut (locking-mode=network_default), vérifie le paramètre associé au default-locking-mode. Dans cette illustration, le réseau est défini sur default-locking-mode=disabled, de sorte qu'aucun trafic ne peut passer par le VIF.

Par exemple, par défaut, les VIF sont créés avec leur locking-mode défini sur network_default. Si vous définissez le default-locking-mode d’un réseau sur disabled, tous les nouveaux VIF pour lesquels vous n’avez pas configuré le mode de verrouillage sont désactivés. Les VIF restent désactivés jusqu’à ce que vous (a) modifiiez le paramètre locking-mode du VIF individuel ou (b) définissiez explicitement le locking-mode du VIF sur unlocked. Ceci est utile lorsque vous faites suffisamment confiance à une VM spécifique pour ne pas vouloir filtrer son trafic du tout.

Pour modifier le paramètre de mode de verrouillage par défaut d’un réseau :

Après avoir créé le réseau, modifiez le mode de verrouillage par défaut en exécutant la commande suivante :

xe network-param-set uuid=network-uuid default-locking-mode=[unlocked|disabled]
<!--NeedCopy-->

Remarque :

Pour obtenir l’UUID d’un réseau, exécutez la commande xe network-list. Cette commande affiche les UUID de tous les réseaux sur l’hôte sur lequel vous avez exécuté la commande.

Pour vérifier le paramètre de mode de verrouillage par défaut d’un réseau :

Exécutez l’une des commandes suivantes :

xe network-param-get uuid=network-uuid param-name=default-locking-mode
<!--NeedCopy-->

xe network-list uuid=network-uuid params=default-locking-mode
<!--NeedCopy-->

Utiliser les paramètres réseau pour le filtrage du trafic VIF

La procédure suivante indique à un VIF sur une machine virtuelle d’utiliser les paramètres default-locking-mode du réseau XenServer sur le réseau lui-même pour déterminer comment filtrer le trafic.

Modifiez l’état de verrouillage du VIF en network_default, s’il n’utilise pas déjà ce mode, en exécutant la commande suivante :
```
xe vif-param-set uuid=vif_uuid locking-mode=network_default

```
Modifiez le mode de verrouillage par défaut en unlocked, s’il n’utilise pas déjà ce mode, en exécutant la commande suivante :
```
xe network-param-set uuid=network-uuid default-locking-mode=unlocked

```

La version officielle de la documentation de ce produit est en anglais. Toute version dans une langue autre que l’anglais est fournie uniquement à titre indicatif et peut inclure du contenu traduit automatiquement. Pour en savoir plus, veuillez consulter la clause de non-responsabilité relative à la traduction automatique sur Cloud Software Group home.

Cela vous a-t-il été utile ?

Gérer la mise en réseau

August 1, 2026

Contributeur:

August 1, 2026

Contributeur:

Dans cet article

Créer des réseaux dans un hôte autonome
Créer des réseaux dans les pools de ressources
Créer des VLAN
Créer des liaisons de cartes réseau sur un hôte autonome
Créer des agrégats de cartes réseau dans des pools de ressources
Configurer une carte réseau de stockage dédiée
Utiliser des cartes réseau compatibles SR-IOV
Contrôler le débit des données sortantes (QoS)
Modifier les options de configuration réseau

Cela vous a-t-il été utile ?