Gérer la mise en réseau

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éation de réseaux dans un hôte autonome

Étant donné que des 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é

• Prise en charge d’opérations avancées telles que les VLAN ou la liaison NIC

Pour plus d’informations sur la façon d’ajouter ou de supprimer des réseaux à l’aide de XenCenter, consultez Ajouter un nouveau réseau dans la documentation XenCenter.

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

Créez le réseau en utilisant 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 des 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 la interface de gestion, utilisé 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 de réseau physique pour les hôtes XenServer dans un pool. Les PIF sur les hôtes individuels sont connectés aux réseaux à l’échelle 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 connecté au réseau Network 0 à l’échelle du pool. Il en va de même pour les hôtes avec des cartes réseau eth1 et Network 1et d’autres cartes réseau présentes dans au moins un hôte XenServer du pool.

Si un hôte XenServer dispose d’un nombre de cartes réseau différent de celui des autres hôtes du pool, des complications peuvent survenir. Des complications peuvent survenir car tous les réseaux de pool ne sont pas valables pour tous les hôtes de pool. Par exemple, si les hôtes host1 et host2 sont dans le même pool et que host1 possède quatre cartes réseau et que host2 n’en possède 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 connecte automatiquement les PIF requis sur les hôtes du pool. Pour plus d’informations, voir pool-vlan-create.

Ouvrez la console 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 la balise VLAN souhaitée. Les UUID et les noms de périphériques de tous les PIF sont renvoyés, y compris tous les VLAN existants :

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

Créez un objet VLAN spécifiant le PIF physique et la balise VLAN souhaités sur toutes les machines virtuelles à connecter au nouveau VLAN. Un nouveau PIF est créé et connecté 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 VM au nouveau réseau. Pour plus d’informations, consultez Création de réseaux dans un hôte autonome.

Créer des liaisons NIC sur un hôte autonome

Nous vous recommandons d’utiliser XenCenter pour créer des liaisons NIC. 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 carte réseau sur des hôtes XenServer qui ne se trouvent pas dans un pool. Pour plus d’informations sur l’utilisation de l’interface de ligne xe pour créer des liaisons de carte réseau sur des hôtes XenServer qui comprennent un pool de ressources, consultez Création de liaisons de carte réseau dans les pools de ressources.

Créer une obligation NIC

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

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. Procédez comme suit :

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

     Tapez 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 liaison 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/NIC utilisé comme interface de gestion. Si l’hôte utilise DHCP, l’adresse MAC de la liaison 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 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 sur l’hôte sont abandonnées.

Vous pouvez contrôler l’adresse MAC d’une liaison de deux manières :

• Un paramètre mac facultatif peut être spécifié dans la commande bond-create . Vous pouvez utiliser ce paramètre pour définir l’adresse MAC de 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 s’il s’agit de l’une 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 (et également 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 le MAC de la première carte réseau nommée.

Rétablir les obligations NIC

Lors du retour 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, 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 lié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 NIC principal fait référence au PIF à partir duquel 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. L’interface de gestion NIC (si l’interface de gestion est l’une des NIC 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. Le premier nommé NIC. Vous pouvez savoir de quoi il s’agit en exécutant la commande suivante :

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

Créer des obligations NIC dans les pools de ressources

Dans la mesure du possible, créez des liaisons NIC dans le cadre de la création initiale du pool de ressources, avant de joindre davantage d’hôtes au pool ou de créer des machines virtuelles. Cela permet à la configuration de 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 NIC à un pool existant nécessite l’une des opérations suivantes :

• Utilisation de l’interface de ligne de commande pour configurer les liaisons sur le coordinateur de pool, puis sur chaque membre du pool.

• Utilisation de l’interface de ligne de commande 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 de mise en réseau sur les hôtes membres avec le coordinateur de pool, de sorte que vous n’avez pas besoin de redémarrer les hôtes membres.

Pour plus de simplicité et pour éviter toute mauvaise configuration, nous vous recommandons d’utiliser XenCenter pour créer des liaisons NIC. Pour plus d’informations, consultez Configuration des cartes réseau.

Cette section décrit l’utilisation de l’interface de ligne xe pour créer des interfaces de carte réseau liées sur des hôtes XenServer qui comprennent un pool de ressources. Pour plus d’informations sur l’utilisation de la CLI xe pour créer des liaisons NIC sur un hôte autonome, consultez Création de liaisons NIC 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 liens perturbe le rythme cardiaque de haute disponibilité en cours et oblige les hôtes à s’auto-isoler (s’arrêter). Les hôtes peuvent ne pas redémarrer correctement et peuvent avoir besoin de la commande host-emergency-ha-disable pour récupérer.

Sélectionnez l’hôte que vous souhaitez voir comme coordinateur de piscine. Par défaut, le coordinateur de pool appartient à 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 Créer une liaison NIC.

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 sur le réseau et la 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 hôte où elle a été configurée à l’origine vers le PIF lié. Autrement dit, l’interface de gestion est désormais absorbée dans l’obligation de sorte que l’obligation entière 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 liens perturbe le rythme cardiaque de haute disponibilité en cours et oblige les hôtes à s’auto-isoler (s’arrêter). 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 la CLI 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 IP XenServer utilisée 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 permet de garantir 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 sorte 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 :

• 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 d’autres interfaces secondaires 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 la liaison pour la résilience de votre trafic de stockage, vous pouvez envisager d’utiliser LACP au lieu de la liaison de pont Linux. Pour utiliser la liaison LACP, vous devez configurer le vSwitch comme pile réseau. Pour plus d’informations, consultez Réseaux vSwitch.

Remarque :

Lors de la sélection d’une carte réseau à configurer comme interface secondaire à utiliser avec les 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 à partir de l’interface de gestion. Si cette règle n’est pas appliquée, le trafic de stockage peut être dirigé vers 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 à la topologie de votre réseau afin de forcer le trafic souhaité sur le PIF sélectionné.

Configurez une configuration IP pour le PIF, en ajoutant des valeurs appropriées pour le paramètre de mode. Si vous utilisez une adresse IP statique, ajoutez les paramètres IP, masque de 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 acheminé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 l’achemine via l’interface appropriée.

• 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 sachiez comment configurer manuellement le réseau Linux.

Utiliser des cartes réseau compatibles SR-IOV

Single Root I/O Virtualization (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 connu sous le nom de fonction physique (PF) tandis que les autres sont connus sous le nom de fonctions virtuelles (VF). L’hyperviseur peut attribuer un 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’un ou plusieurs VF NIC à une machine virtuelle permet à son trafic réseau de contourner le commutateur virtuel. Une fois configuré, chaque machine virtuelle se comporte comme si elle utilisait directement la carte réseau, réduisant ainsi la surcharge de traitement et améliorant les performances.

Avantages du SR-IOV

Un VF SR-IOV a de meilleures performances qu’un VIF. Il peut assurer la séparation matérielle entre le trafic provenant 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 :

• Activez SR-IOV sur les cartes réseau qui prennent en charge SR-IOV.

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

• Gérez les VF SR-IOV comme un pool de ressources VF.

• Affecter des VF SR-IOV à une VM.

• Configurer les VF SR-IOV (par exemple, adresse MAC, VLAN, débit).

• Exécutez des tests pour confirmer si SR-IOV est pris en charge dans le cadre du kit de certification automatisé.

Configuration du système

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

• Virtualisation MMU E/S (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 plus d’informations sur la configuration du microprogramme 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 Réseau pour créer et activer un réseau SR-IOV sur une carte réseau.

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

Dans XenCenter, au niveau de la machine virtuelle, utilisez l’assistant Ajouter une interface virtuelle dans l’onglet Réseau pour ajouter un réseau compatible SR-IOV comme interface virtuelle pour cette machine virtuelle. Pour plus d’informations, voir 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 Liste de compatibilité matérielle. Consultez la documentation fournie par le fournisseur pour un invité particulier pour déterminer s’il prend en charge SR-IOV.

Limites

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

• Un VF SR-IOV et un VIF normal de la même carte réseau peuvent ne pas être en mesure de communiquer entre eux 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 certains VF SR-IOV ne prennent pas effet car ils ne prennent pas en charge la limitation de la vitesse du réseau.

• L’exécution d’une migration en direct, d’une suspension et d’un 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, le 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 VM dispose d’un VF SR-IOV, les fonctions nécessitant une migration en direct ne sont pas possibles. Cela est dû au fait que la machine virtuelle est directement liée à la carte réseau VF compatible SR-IOV physique.

• SR-IOV peut être utilisé dans un environnement qui utilise une haute disponibilité. Cependant, SR-IOV n’est pas pris en compte dans la planification des capacités. Les machines virtuelles auxquelles des VF SR-IOV sont attribués sont redémarrées dans la mesure du possible lorsqu’un hôte du pool dispose des ressources appropriées. Ces ressources incluent SR-IOV activé sur le bon réseau et un VF gratuit.

• Les VF SR-IOV ne sont pas pris en charge par l’accélérateur PVS.

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

En général, 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 le régler 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 maximum de VF à 4 pour le pilote igb , éditez /etc/modprobe.d/igb.conf pour lire :

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

• Effectuez les modifications avant d’activer SR-IOV.

CLI

Voir Commandes SR-IOV pour obtenir des instructions CLI sur la création, la suppression, l’affichage de réseaux SR-IOV et l’attribution d’un VF SR-IOV à une machine virtuelle.

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

Pour limiter la quantité de données sortantes qu’une machine virtuelle peut envoyer par seconde, définissez une valeur de qualité de service (QoS) facultative sur les interfaces virtuelles (VIF) de la machine virtuelle. Le paramètre vous permet de spécifier un débit de transmission maximal pour les paquets sortants en kilo-octets par seconde.

La valeur de qualité de service limite le taux de transmission de la VM. Le paramètre Qualité de service ne limite pas la quantité de données que la machine virtuelle 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).

En fonction de 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 machine virtuelle à l’un des deux emplacements suivants. Vous pouvez définir cette valeur en utilisant la CLI xe ou dans XenCenter.

• XenCenter Vous pouvez définir la valeur limite du taux 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 taux de transmission de la qualité de service à l’aide de la CLI à l’aide des commandes de la section suivante.

Exemple de commande CLI pour QoS

Pour limiter un VIF à un débit de transmission maximal de 100 kilo-octets 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 kilo-octets par seconde (kBps), 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. Il comprend :

• Modification du nom d’hôte (c’est-à-dire du nom du système de noms de domaine (DNS))

• Ajout ou suppression de serveurs DNS

• Changer les adresses IP

• Modification de la carte réseau utilisée comme interface de gestion

• Ajout d’une nouvelle carte réseau physique au serveur

• Ajouter un objectif à un réseau

• Activation du filtrage ARP (verrouillage du port du commutateur)

Hostname

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 à l’échelle 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 de manière dynamique 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 un PIF avec une IP statique :

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

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

Vous pouvez utiliser la CLI 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 de l’adresse IP d’un PIF, utilisez la commande CLI pif-reconfigure-ip . Voir pif-reconfigure-ip pour plus de détails sur les paramètres de la commande pif-reconfigure-ip . Consultez la section suivante pour obtenir des informations sur la modification des adresses IP des hôtes dans les pools de ressources.

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

Les hôtes XenServer dans les pools de ressources disposent d’une adresse IP de gestion unique 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 apportée, les connexions au stockage réseau peuvent être perdues. Lorsque cela se produit, le stockage doit être rebranché à 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 en dehors de l’hôte avant de modifier sa configuration IP.

Utilisez la commande CLI pif-reconfigure-ip pour définir l’adresse IP comme vous le souhaitez. 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 du coordinateur de pool nécessite des étapes supplémentaires. En effet, chaque membre du pool utilise l’adresse IP annoncée du coordinateur du pool pour la communication. Les membres du pool ne savent pas comment contacter le coordinateur du pool lorsque son adresse IP change.

Dans la mesure du possible, utilisez une adresse IP dédiée qui n’est pas susceptible 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 vous le souhaitez :

  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 lorsqu’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 à l’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 la 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 émise 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 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. Toutefois, avant de fermer le port 80, vérifiez si tous vos clients API (Citrix Virtual Apps et 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 à la gestion

Pour désactiver complètement 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 sur 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é (actuellement connecté ( RO) : false). Pour l’afficher, 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 réseau, utilisez la commandexe network-param-add:

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

Pour supprimer un objectif réseau, utilisez la commandexe network-param-remove:

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

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

Utiliser le verrouillage du port du commutateur

La fonction de verrouillage du port de commutation XenServer vous permet de contrôler le trafic envoyé à partir de 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 commutation vous permet de simplifier la configuration de votre 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 envoyé par un invité non fiable. Cela limite la capacité de l’invité à prétendre qu’il possède une adresse MAC ou IP qu’il ne possède 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 qu’il peut utiliser

• Intercepter, usurper ou perturber le trafic d’autres machines virtuelles

Exigences

• La fonction de verrouillage du port du commutateur XenServer est prise en charge sur le pont Linux et les piles réseau vSwitch.

• Lorsque vous activez le contrôle d’accès basé sur les rôles (RBAC) dans votre environnement, l’utilisateur qui configure le verrouillage des ports de commutateur doit être connecté avec un compte disposant au moins d’un rôle d’opérateur de pool ou d’administrateur de pool. Lorsque le contrôle d’accès en fonction du rôle n’est pas activé dans votre environnement, l’utilisateur doit être connecté avec le compte racine du coordinateur de pool.

• Lorsque vous exécutez les commandes de verrouillage du port du commutateur, les réseaux peuvent être en ligne ou hors ligne.

• Dans les invités Windows, l’icône Réseau déconnecté apparaît uniquement lorsque XenServer VM Tools est installé sur 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 des ports de commutateur n’est pas prise en charge lorsque des contrôleurs tiers sont utilisés dans l’environnement.

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

• Exécution d’une attaque au niveau IP sur un autre locataire/utilisateur. Cependant, le verrouillage du port du 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 du port du commutateur est configuré : a) se faire passer pour un autre locataire dans le cloud ou un autre utilisateur ou b) lancer une interception de trafic destiné à un autre utilisateur.

• Épuisement des ressources du réseau.

• Réception d’un trafic destiné à d’autres machines virtuelles via des comportements d’inondation de commutateur normaux (pour les adresses MAC de diffusion ou les adresses MAC de destination inconnues).

De même, le verrouillage des ports de commutation ne limite pas l’endroit où une machine virtuelle peut envoyer du trafic.

Notes de mise en œuvre

Vous pouvez implémenter la fonctionnalité de verrouillage du port de commutation à l’aide de la ligne de commande ou de 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 des ports de commutateur peut empêcher 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 du port du commutateur peut empêcher l’usurpation d’identité ARP :

L’usurpation d’identité 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’identité ARP peut potentiellement entraîner l’envoi du trafic du nœud à l’attaquant. 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) souhaite 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 souhaite utiliser l’usurpation d’identité ARP pour prétendre que sa machine virtuelle, 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 : étant donné que l’administrateur a activé le verrouillage du port du commutateur, ces paquets sont tous abandonnés, car l’activation du verrouillage du port du commutateur empêche l’emprunt 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 : la VM-a reçoit la réponse ARP de la VM-b.

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

L’usurpation d’adresse IP est un processus qui masque 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, Host-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 vers un système distant.

Résultat : les paquets Host-C sont abandonnés. Cela est dû au fait que l’administrateur a activé le verrouillage du port du commutateur. Les paquets Host-C sont abandonnés car l’activation du verrouillage du port du 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 c_MAC d’origine.

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

Résultat : les paquets Host-C sont abandonnés. Cela est dû au fait que l’administrateur a activé le verrouillage du port du commutateur, ce qui empêche l’usurpation d’identité.

Exemple 3 : Hébergement Web :

Scénario:

Alice est administratrice d’infrastructure.

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

Alice reconfigure le VIF de l’hôte B pour qu’il soit verrouillé sur un seul MAC mais sur plusieurs adresses IP.

Comment fonctionne le verrouillage des ports de commutation

La fonction de verrouillage du port du 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 définir le VIF pour empêcher la machine virtuelle d’envoyer du trafic, restreindre le VIF afin qu’il ne puisse envoyer du trafic qu’à l’aide de 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 fait référence au paramètre de verrouillage au niveau du réseau pour déterminer le trafic à autoriser.

Quelle 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 qui suivent, le pont Linux ne prend pas entièrement en charge le verrouillage des ports de commutation dans IPv6.

États du mode de verrouillage VIF

La fonction de verrouillage du port du 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 le VIF est connecté à une machine virtuelle en cours d’exécution.

• Réseau_par défaut. 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 paramètre de mode de verrouillage par défaut du réseau associé est défini sur désactivé ou déverrouillé :

  -default-locking-mode=désactivé, XenServer applique une règle de filtrage afin 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 du mode de verrouillage par défaut est défini sur déverrouillé.

  Pour plus d’informations sur le paramètre default-locking-mode , voir 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 autre que network_default.

  Remarque :

  Vous ne pouvez pas modifier le mode de verrouillage par défaut d’un réseau auquel sont attachés des VIF actifs.

• 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 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 vous avez configuré le pont Linux, ne saisissez pas d’adresses IPv6.

  XenServer vous permet de taper 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 Neighbor Discovery Protocol (NDP). Par conséquent, une protection complète ne peut pas être mise en œuvre et les invités pourraient se faire passer pour un autre invité en falsifiant des paquets NDP. Par conséquent, si vous spécifiez ne serait-ce qu’une seule adresse IPv6, XenServer laisse tout le trafic IPv6 passer par la VIF. Si vous ne spécifiez aucune adresse IPv6, XenServer ne laisse pas le trafic IPv6 passer vers la VIF.

• Débloqué. 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é à traverser le VIF. (C’est-à-dire que XenServer applique une règle de filtrage afin que la VIF abandonne tout le trafic.)

Configurer le verrouillage du port du commutateur

Cette section propose trois procédures différentes :

• Restreindre les VIF pour 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 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 plusieurs adresses 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).

Modifiez le mode de verrouillage par défaut sur 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 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 l’appareil indique le numéro de l’appareil 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 permettant de 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 un VIF à utiliser 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 provenant d’un réseau spécifique

La procédure suivante empêche une machine virtuelle de communiquer via un VIF spécifique. Lorsqu’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 provenant d’un réseau spécifique. Cela offre un niveau de contrôle plus précis 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 être présente, cependant, 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 l’appareil indique le numéro de l’appareil 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 machine virtuelle et en cliquant sur Désactiver.

Supprimer la restriction d’un VIF à une adresse IP

Pour revenir à l’état de mode de verrouillage par défaut (d’origine), utilisez la procédure suivante. Par défaut, lorsque vous créez une VIF, XenServer la configure de sorte qu’elle ne soit pas limitée à l’utilisation d’une adresse IP spécifique.

Pour rétablir un VIF à un état déverrouillé, modifiez le mode de verrouillage par défaut du VIF sur 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-->

Simplifiez la configuration du mode de verrouillage VIF dans le Cloud

Plutôt que d’exécuter les commandes du 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 la manière dont les paquets sont filtrés, comme décrit dans la section précédente Fonctionnement du verrouillage des ports de commutation.

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

• Débloqué. Lorsque le paramètre réseau default-locking-mode 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 se connecte.

• Désactivé. Lorsque le paramètre default-locking-mode est défini sur désactivé, XenServer applique une règle de filtrage afin que le VIF supprime tout le trafic.

Par défaut, le mode de verrouillage par défaut pour tous les réseaux créés dans XenCenter et utilisant la CLI est défini sur déverrouillé.

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, lorsque le mode de verrouillage d'un VIF est défini sur son paramètre par défaut (`network_default`), le VIF utilise le mode de verrouillage par défaut du réseau pour déterminer son comportement.

Par exemple, par défaut, les VIF sont créés avec leur mode de verrouillage défini sur network_default. Si vous définissez le mode de verrouillage par défaut d'un réseau=désactivé, 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) changiez le paramètre de mode de verrouillage du VIF individuel ou (b) définissiez explicitement le mode de verrouillage du VIF sur « déverrouillé ». Cela est utile lorsque vous faites suffisamment confiance à une machine virtuelle spécifique et que vous ne souhaitez donc pas 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 de 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 du réseau XenServer default-locking-mode sur le réseau lui-même pour déterminer comment filtrer le trafic.

1. Modifiez l’état de verrouillage 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 déverrouillé, 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-->