Gestion du réseau

Les procédures de configuration réseau dans 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.

Étant donné que 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 des hôtes individuels sont connectés aux réseaux du pool en fonction du nom du périphérique. Par exemple, tous les hôtes XenServer d’un pool avec une carte réseau eth0 ont un PIF correspondant branché au réseau Network 0 du pool. Il en va de même pour les hôtes avec des cartes réseau eth1 et Network 1, et d’autres cartes réseau présentes dans au moins un hôte XenServer du pool.

Si un hôte XenServer a un nombre de cartes réseau différent de celui 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 à eth0 et eth1 sont valides sur host2. Les machines virtuelles sur host1 avec des VIF connectés aux réseaux correspondant à eth2 et eth3 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 des machines virtuelles au nouveau réseau. Pour plus d’informations, consultez Création de réseaux sur 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 décrit comment utiliser l’interface de ligne de commande xe pour lier des interfaces de cartes 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.

1. 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
   <!--NeedCopy-->
   

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

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

3. 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
      <!--NeedCopy-->
     

     Saisissez deux UUID lorsque vous liez deux cartes réseau et quatre UUID lorsque vous liez quatre cartes réseau. L’UUID de la liaison est renvoyé après l’exécution de la commande.

   • Pour configurer la liaison 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
      <!--NeedCopy-->
     

Contrôler l’adresse MAC de la liaison

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

Vous pouvez modifier l’adresse MAC de la liaison afin qu’elle soit différente de l’adresse MAC de la carte réseau de l’interface de gestion (actuelle). Cependant, lorsque la liaison est activée 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’une liaison 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 la liaison 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 la liaison. Si l’interface de gestion ne fait pas partie de la liaison, mais qu’une autre interface de gestion en fait partie, la liaison utilise l’adresse MAC (ainsi que l’adresse IP) de cette interface de gestion. Si aucune des cartes réseau de la liaison n’est une interface de gestion, la liaison utilise l’adresse MAC de la première carte réseau nommée.

Annuler les liaisons de cartes réseau

Lors de la restauration de l’hôte XenServer à une configuration non liée, la commande bond-destroy configure automatiquement la carte réseau principale comme interface pour l’interface de gestion. Par conséquent, toutes les VIF sont déplacées vers l’interface de gestion. Si l’interface de gestion d’un hôte se trouve sur une interface liée VLAN étiqueté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 dont la configuration MAC et IP a été copiée lors de la création de la liaison. Lors de la liaison de deux cartes réseau, la carte réseau principale est :

1. La carte réseau de l’interface de gestion (si l’interface de gestion est l’une des cartes réseau liées).

2. Toute autre carte réseau avec une adresse IP (si l’interface de gestion ne faisait pas partie de la liaison).

3. La première carte réseau nommée. Vous pouvez savoir de quelle carte il s’agit en exécutant la commande suivante :

   xe bond-list params=all
   <!--NeedCopy-->
   

Créer des liaisons de cartes réseau dans les pools de ressources

Dans la mesure du possible, créez des liaisons de cartes réseau 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 de répliquer automatiquement la configuration de la liaison vers 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 à un pool existant nécessite l’une des opérations suivantes :

• Utilisation de la CLI pour configurer les liaisons sur le coordinateur de pool, puis sur chaque membre du pool.

• Utilisation de la 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. Pour plus d’informations, consultez (/fr-fr/xencenter/current-release/hosts-nics.html).

Cette section décrit l’utilisation de l’interface de ligne de commande xe pour créer des interfaces de cartes réseau 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 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 être récupérés.

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 la 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 comme décrit dans (/fr-fr/xenserver/8/networking/manage.html#create-a-nic-bond).

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 de réseau et de liaison sont automatiquement répliquées vers le nouvel hôte. L’interface de gestion est automatiquement déplacée de la carte réseau 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 soit :

• 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.

Si vous utilisez l’agrégation de liens pour la résilience de votre trafic de stockage, envisagez d’utiliser LACP plutôt que l’agrégation de liens (obsolète) du pont Linux. Pour utiliser l’agrégation de liens LACP, vous devez configurer le vSwitch comme pile réseau. Pour plus d’informations, consultez Sélection de la pile réseau.

Remarque :

Lorsque vous sélectionnez une carte réseau à configurer comme interface secondaire à utiliser 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 dans lequel les interfaces réseau sont initialisées.

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é via 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ées 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 VM permet à son trafic réseau de contourner le commutateur virtuel. Une fois configurée, chaque VM 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 VM 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 prennent en charge le SR-IOV.

• Désactiver le SR-IOV sur les cartes réseau qui prennent en charge le SR-IOV.

• Gérer les VF SR-IOV en tant que pool de ressources VF.

• Attribuer des VF SR-IOV à une VM.

• 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 E/S MMU (AMD-Vi et Intel VT-d)

• Interprétation d’ID de routage alternative (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 firmware 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 (au niveau de la 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 une liste des plateformes 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 le 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 le 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 machines virtuelles de communiquer, assurez-vous que la communication utilise le modèle VF à VF ou VIF à VIF, et non VF à VIF.

• Les paramètres de qualité de service pour certaines VF SR-IOV ne prennent pas effet car elles 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 une 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 le SR-IOV.

• Si votre machine virtuelle possède une VF SR-IOV, les fonctions qui nécessitent la migration en direct ne sont pas possibles. Cela est dû au fait que la machine virtuelle est directement liée à la VF de la carte réseau physique compatible SR-IOV.

• Le SR-IOV peut être utilisé dans un environnement qui utilise la haute disponibilité. Cependant, le SR-IOV n’est pas pris en compte dans la planification de la capacité. Les machines virtuelles auxquelles des VF SR-IOV sont attribuées 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 le SR-IOV activé sur le bon réseau et une VF libre.

• Les VF SR-IOV ne sont pas prises 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 du 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 se 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 le SR-IOV.

CLI

Consultez 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 (VIF) de la VM. 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 (VIF) de la VM à deux endroits. Vous pouvez définir cette valeur soit en utilisant la 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 à l’aide de la CLI en utilisant les commandes de la section suivante.

Exemple de commande CLI pour la QoS

Pour limiter une VIF à un débit de transmission maximal de 100 kilooctets par seconde à l’aide de la 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 de 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 DNS, est défini dans la base de données de l’ensemble du pool et 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 dans les 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é. Voir 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 entrent 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 quel 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 de PIF de tous les hôtes du pool. Utilisez la commande pif-param-list pour vérifier la configuration d’adressage IP du PIF 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 pool-management-reconfigure pour modifier le PIF utilisé 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é, vous pouvez fermer le port TCP 80 sur l’interface de gestion. Par défaut, le port 80 est toujours ouvert. Si vous le fermez, tous les clients externes qui utilisent l’interface de gestion doivent utiliser HTTPS sur le port 443 pour se connecter à XenServer. Cependant, avant de fermer le port 80, vérifiez si tous vos clients API (Citrix Virtual Apps and Desktops en particulier) peuvent utiliser HTTPS sur le port 443.

Pour 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

1. Installez une nouvelle carte réseau physique sur votre hôte XenServer de la manière habituelle.
2. Redémarrez votre hôte XenServer.

3. Répertoriez toutes les cartes réseau physiques de cet hôte XenServer à l’aide de la commande suivante :

   xe pif-list host-uuid=<host_uuid>
   

4. 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.

5. Répertoriez à 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>
   

6. 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 CLI xe 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 des ports de commutateur

La fonction de verrouillage des ports 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 des ports 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

Prérequis

• La fonction de verrouillage de port de commutateur XenServer est prise en charge sur les piles réseau Linux bridge (obsolète) et vSwitch.

• 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 le faire et que le verrouillage de port de commutateur est configuré : a) usurper l’identité d’un autre locataire ou utilisateur dans le cloud 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 VM 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 grands environnements où l’automatisation est une préoccupation majeure, la méthode d’implémentation la plus typique 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, VM-c est une machine virtuelle qu’un locataire hostile (Locataire C) loue et utilise pour des attaques. 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 indiquer 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 VM-a à la machine virtuelle B (VM-b) en l’adressant à l’adresse IP de VM-b. Le propriétaire de la machine virtuelle C veut utiliser l’usurpation d’ARP pour faire croire que sa VM, VM-c, est en fait VM-b.

1. VM-c envoie un flux spéculatif de réponses ARP à 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 : Parce 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é.

2. VM-b envoie une réponse ARP à VM-a, affirmant que l’adresse MAC dans la réponse (b_MAC) est associée à l’adresse IP, b_IP.

   Résultat : VM-a reçoit la réponse ARP de 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 à l’aide de son hôte, Hôte-C, sur un système distant pour masquer 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. Cela est dû au fait que l’administrateur a activé le verrouillage de port de commutateur. Les paquets de l’Hôte-C sont abandonnés car l’activation du verrouillage de port 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 c_MAC d’origine.

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. Cela est dû au fait que l’administrateur a activé le verrouillage de port 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 à partir de 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 l’interface VIF de l’Hôte-B pour qu’elle soit verrouillée à une seule adresse MAC mais à plusieurs adresses IP.

Fonctionnement du verrouillage de port de commutateur

La fonctionnalité de verrouillage de port 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 le VIF déterminent la manière dont les paquets sont filtrés. Vous pouvez configurer le VIF pour empêcher la machine virtuelle d’envoyer tout trafic, restreindre le VIF afin qu’il ne puisse envoyer du trafic qu’en utilisant son adresse IP attribuée, ou autoriser la machine virtuelle à envoyer du trafic à n’importe quelle adresse IP sur le réseau connecté au VIF.

• Niveau réseau. Le réseau XenServer détermine la manière dont les paquets sont filtrés. Lorsque le mode de verrouillage d’un 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.

Quel que soit la pile réseau que vous utilisez, la fonctionnalité fonctionne de la même manière. Cependant, comme décrit plus en détail dans les sections suivantes, le pont Linux (obsolète) ne prend pas entièrement en charge le verrouillage de port de commutateur en IPv6.

États du mode de verrouillage 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 ne s’appliquent que lorsque le VIF est connecté à une machine virtuelle en cours d’exécution.

• Network_default. Lorsque l’état du 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 le 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 le VIF supprime tout le trafic.

  -default-locking-mode=déverrouillé, XenServer supprime toutes les règles de filtrage associées au 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és 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 qui a des VIF actifs attachés.

• 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 le VIF. Dans ce mode, si aucune adresse IP n’est spécifiée, la machine virtuelle ne peut envoyer aucun trafic via ce VIF, sur ce réseau.

  Pour spécifier les adresses IP à partir desquelles le VIF accepte le trafic, utilisez les adresses IP IPv4 ou IPv6 en utilisant les paramètres ipv4_allowed ou ipv6_allowed. Cependant, si le pont Linux (obsolète) est configuré, ne saisissez pas d’adresses IPv6.

  XenServer vous permet de saisir des adresses IPv6 lorsque le pont Linux est actif. Cependant, XenServer ne peut pas filtrer en fonction des adresses IPv6 saisies. La raison est que le pont Linux ne dispose pas de modules pour filtrer les paquets du protocole de découverte de voisins (NDP). Par conséquent, une protection complète ne peut pas être mise en œuvre et les invités pourraient usurper l’identité d’un autre invité en falsifiant des paquets NDP. En conséquence, si vous spécifiez ne serait-ce qu’une seule adresse IPv6, XenServer laisse tout le trafic IPv6 passer par le VIF. Si vous ne spécifiez aucune adresse IPv6, XenServer ne laisse aucun trafic IPv6 passer vers le VIF.

  Remarque :

  La pile réseau du pont Linux est obsolète et sera supprimée dans une future version.

• Déverrouillé. Tout le trafic réseau peut passer par le VIF. Autrement dit, aucun filtre n’est appliqué au trafic entrant ou sortant du VIF.

• Désactivé. Aucun trafic n’est autorisé à passer par le VIF. (Autrement dit, XenServer applique une règle de filtrage de sorte que le VIF supprime tout le trafic.)

Configurer le verrouillage des ports de commutateur

Cette section présente trois procédures différentes :

• Restreindre les VIFs à utiliser une adresse IP spécifique

• Ajouter une adresse IP à une liste restreinte existante. Par exemple, pour ajouter une adresse IP à un VIF lorsque la VM 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 VIFs 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 VM).

Changez le mode de verrouillage par défaut en « 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-->

Le vif-uuid représente l’UUID de la 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 de la 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 adresses IP IPv4 de destination. Par exemple :

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

• Spécifiez une ou plusieurs adresses IP IPv6 de destination. 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 une VIF à l’utilisation d’une adresse IP spécifique, vous pouvez ajouter une ou plusieurs adresses IP que la 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 restreignez 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 le VIF pour définir le mode de verrouillage du VIF. La commande modifie les règles de filtrage pendant l’exécution du VIF. Dans ce cas, la connexion réseau semble toujours présente, mais le VIF supprime tous les paquets que la VM tente d’envoyer.

Conseil :

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

Pour empêcher un VIF de recevoir du trafic, désactivez le VIF connecté 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 le 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’un 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 limité à 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 permet au réseau XenServer de déterminer comment les paquets sont filtrés, comme décrit dans la section précédente Fonctionnement du verrouillage des ports 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 pour 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’une locking-mode de VIF est définie sur son paramètre par défaut (network_default), le VIF utilise le default-locking-mode du réseau pour déterminer son comportement.

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-->

OU

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.

1. Modifiez l’état de verrouillage du VIF sur 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
   <!--NeedCopy-->
   

2. Modifiez le mode de verrouillage par défaut sur 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
   <!--NeedCopy-->