XenServer

Hôtes et pools de ressources

Cette section décrit comment les pools de ressources peuvent être créés à l’aide d’une série d’exemples à l’aide de l’interface de ligne de commande (CLI) xe. Une configuration simple de stockage partagé basée sur NFS est présentée et plusieurs exemples simples de gestion de machines virtuelles sont présentés. Il contient également des procédures pour traiter les défaillances de nœuds physiques.

Présentation des hôtes et des pools de ressources XenServer

Un Pool de ressources comprend plusieurs installations d’hôtes XenServer, liées ensemble à une seule entité gérée pouvant héberger des machines virtuelles. S’il est associé à un stockage partagé, un pool de ressources permet de démarrer des machines virtuelles quelconque XenServer qui dispose de suffisamment de mémoire. Les machines virtuelles peuvent ensuite être déplacées dynamiquement entre les hôtes XenServer pendant l’exécution avec un temps d’arrêt minimal (migration en direct). Si un hôte XenServer individuel subit une défaillance matérielle, l’administrateur peut redémarrer les machines virtuelles ayant échoué sur un autre hôte XenServer du même pool de ressources. Lorsque la haute disponibilité est activée sur le pool de ressources, les machines virtuelles sont automatiquement déplacées vers un autre hôte en cas de défaillance de leur hôte. Jusqu’à 64 hôtes sont pris en charge par pool de ressources, bien que cette restriction ne soit pas appliquée.

Un pool a toujours au moins un nœud physique, appelé Coordinateur de piscine (anciennement « Pool Master »). Le nœud coordinateur expose une interface d’administration (utilisée par XenCenter et l’interface de ligne de commande XenServer, connue sous le nom d’interface de ligne de commande xe). Le coordonnateur transmet les ordres aux membres individuels si nécessaire.

Remarque :

En cas d’échec du coordinateur de pool, la réélection du coordinateur n’a lieu que si la haute disponibilité est activée.

Configuration requise pour la création de pools de ressources

Un pool de ressources est un agrégat homogène (ou hétérogène avec des restrictions) d’un ou plusieurs hôtes XenServer, jusqu’à un maximum de 64. La définition d’homogène est la suivante :

  • Les processeurs de l’hôte rejoignant le pool sont les mêmes (en termes de fournisseur, de modèle et de fonctionnalités) que les processeurs des hôtes déjà dans le pool.

  • L’hôte qui rejoint le pool exécute la même version du logiciel XenServer, au même niveau de correctif, que les hôtes déjà dans le pool.

Le logiciel impose des contraintes supplémentaires lors de la jonction d’un hôte à un pool. En particulier, XenServer vérifie que les conditions suivantes sont remplies pour l’hôte rejoignant le pool :

  • L’hôte n’est pas membre d’un pool de ressources existant.

  • Aucun stockage partagé n’est configuré sur l’hôte.

  • L’hôte n’héberge aucune machine virtuelle en cours d’exécution ou suspendue.

  • Aucune opération active n’est en cours sur les machines virtuelles de l’hôte, telle que l’arrêt d’une machine virtuelle.

  • L’horloge de l’hôte est synchronisée en même temps que celle du coordinateur de pool (par exemple, à l’aide de NTP).

  • L’interface de gestion de l’hôte n’est pas liée. Vous pouvez configurer l’interface de gestion lorsque l’hôte rejoint le pool.

  • L’adresse IP de gestion est statique, soit configurée sur l’hôte lui-même, soit à l’aide d’une configuration appropriée sur votre serveur DHCP.

Les hôtes XenServer dans les pools de ressources peuvent contenir différents nombres d’interfaces réseau physiques et avoir des référentiels de stockage locaux de taille variable. En pratique, il est souvent difficile d’obtenir plusieurs hôtes avec exactement les mêmes processeurs, et des variations mineures sont donc autorisées. S’il est acceptable d’avoir des hôtes avec des processeurs différents dans le même pool, vous pouvez forcer l’opération de jonction de pool en passant la commande --force paramètre.

Tous les hôtes du pool doivent se trouver sur le même site et être connectés par un réseau à faible latence.

Remarque :

Les serveurs fournissant un stockage NFS ou iSCSI partagé pour le pool doivent disposer d’une adresse IP statique.

Un pool doit contenir des référentiels de stockage partagés pour sélectionner l’hôte XenServer sur lequel exécuter une machine virtuelle et pour déplacer une machine virtuelle entre les hôtes XenServer de manière dynamique. Si possible, créez un pool une fois que le stockage partagé est disponible. Nous vous recommandons de déplacer les machines virtuelles existantes avec des disques situés dans le stockage local vers le stockage partagé après avoir ajouté du stockage partagé. Vous pouvez utiliser l’icône xe vm-copy ou utilisez XenCenter pour déplacer des machines virtuelles.

Créer un pool de ressources

Les pools de ressources peuvent être créés à l’aide de XenCenter ou de l’interface de ligne de commande. Lorsqu’un nouvel hôte rejoint un pool de ressources, l’hôte qui le rejoint synchronise sa base de données locale avec celle à l’échelle du pool et hérite de certains paramètres du pool :

  • La configuration de la machine virtuelle, du stockage local et distant est ajoutée à la base de données à l’échelle du pool. Cette configuration est appliquée à l’hôte qui rejoint le pool, sauf si vous partagez explicitement les ressources après que l’hôte a rejoint le pool.

  • L’hôte de jonction hérite des référentiels de stockage partagés existants dans le pool. Les enregistrements PBD appropriés sont créés afin que le nouvel hôte puisse accéder automatiquement au stockage partagé existant.

  • Les informations de mise en réseau sont partiellement héritées de l’hôte de jonction : le structural les détails des cartes réseau, des VLAN et des interfaces liées sont tous hérités, mais politique l’information ne l’est pas. Ces informations de stratégie, qui doivent être reconfigurées, comprennent :

    • Adresses IP des cartes réseau de gestion, qui sont conservées à partir de la configuration d’origine.

    • L’emplacement de l’interface de gestion, qui reste le même que la configuration d’origine. Par exemple, si les autres hôtes de pool ont des interfaces de gestion sur une interface liée, l’hôte de jonction doit être migré vers la liaison après la jonction.

    • Des cartes réseau de stockage dédiées, qui doivent être réaffectées à l’hôte de jonction à partir de XenCenter ou de l’interface de ligne de commande, et des PBD rebranchés pour acheminer le trafic en conséquence. Cela est dû au fait que les adresses IP ne sont pas attribuées dans le cadre de l’opération de jonction de pool et que la carte réseau de stockage ne fonctionne que lorsqu’elle est correctement configurée. Pour plus d’informations sur la façon de dédier une carte réseau de stockage à partir de l’interface de ligne de commande, reportez-vous à la section Gérer la mise en réseau.

Remarque :

Vous ne pouvez joindre un nouvel hôte à un pool de ressources que si l’interface de gestion de l’hôte se trouve sur le même VLAN balisé que celui du pool de ressources.

Ajouter un hôte à un pool à l’aide de l’interface de ligne de commande xe

Remarque :

Nous vous recommandons de mettre à jour votre pool et l’hôte de jonction au même niveau avant de tenter la jonction.

  1. Ouvrez une console sur l’hôte XenServer que vous souhaitez joindre à un pool.

  2. Rejoignez l’hôte XenServer au pool en exécutant la commande :

      xe pool-join master-address=<address of pool coordinator> master-username=<administrator username> master-password=<password>
    <!--NeedCopy-->
    

    Le adresse-maître doit être défini sur le nom de domaine complet du coordinateur du pool. Le mot de passe Il doit s’agir du mot de passe administrateur défini lors de l’installation du coordinateur de pool.

Remarque :

Lorsque vous joignez un hôte à un pool, le mot de passe administrateur de l’hôte de jonction est automatiquement modifié pour correspondre au mot de passe administrateur du coordinateur de pool.

Par défaut, les hôtes XenServer appartiennent à un pool sans nom. Pour créer votre premier pool de ressources, renommez le pool sans nom existant. Utilisez tab-complete pour trouver le pool_uuid:

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

Créer des pools de ressources hétérogènes

XenServer simplifie l’expansion des déploiements au fil du temps en permettant de joindre du matériel hôte disparate à un pool de ressources, appelé pool de ressources hétérogènes. Les pools de ressources hétérogènes sont rendus possibles par l’utilisation de technologies dans les processeurs Intel (FlexMigration) et AMD (Extended Migration) qui fournissent le « masquage » ou le « nivellement » du processeur. Les fonctions de masquage et de nivellement du processeur permettent de configurer un processeur pour Apparaître comme fournissant une marque, un modèle ou une fonctionnalité différente de ce qu’elle fait réellement. Cette fonctionnalité vous permet de créer des pools d’hôtes avec des processeurs disparates, tout en prenant en charge en toute sécurité la migration en direct.

Remarque :

Les processeurs des hôtes XenServer rejoignant des pools hétérogènes doivent appartenir au même fournisseur (c’est-à-dire AMD, Intel) que les processeurs des hôtes déjà dans le pool. Toutefois, il n’est pas nécessaire que les hôtes soient du même type au niveau de la famille, du modèle ou des numéros de pas.

XenServer simplifie la prise en charge des pools hétérogènes. Il est désormais possible d’ajouter des hôtes à des pools de ressources existants, quel que soit le type de processeur sous-jacent (à condition que le processeur appartienne à la même famille de fournisseurs). L’ensemble des fonctionnalités du pool est calculé dynamiquement à chaque fois que :

  • Un nouvel hôte rejoint le pool

  • Un membre de la piscine quitte la piscine

  • Un membre du pool se reconnecte après un redémarrage

Toute modification de l’ensemble de fonctionnalités du pool n’affecte pas les machines virtuelles qui s’exécutent actuellement dans le pool. Une machine virtuelle en cours d’exécution continue d’utiliser l’ensemble de fonctionnalités qui a été appliqué lors de son démarrage. Cet ensemble de fonctionnalités est corrigé au démarrage et persiste tout au long des opérations de migration, de suspension et de reprise. Si le niveau du pool diminue lorsqu’un hôte moins performant rejoint le pool, une machine virtuelle en cours d’exécution peut être migrée vers n’importe quel hôte du pool, à l’exception de l’hôte nouvellement ajouté. Lorsque vous déplacez ou migrez une machine virtuelle vers un autre hôte au sein d’un pool ou entre eux, XenServer compare l’ensemble des fonctionnalités de la machine virtuelle à l’ensemble des fonctionnalités de l’hôte de destination. Si les ensembles de fonctionnalités sont compatibles, la machine virtuelle est autorisée à migrer. Cela permet à la machine virtuelle de se déplacer librement au sein des pools et entre eux, quelles que soient les fonctionnalités de processeur qu’elle utilise. Si vous utilisez l’équilibrage de la charge de travail pour sélectionner un hôte de destination optimal pour la migration de votre machine virtuelle, un hôte avec un ensemble de fonctionnalités incompatibles ne sera pas recommandé comme hôte de destination.

Ajouter un espace de stockage partagé

Pour obtenir la liste complète des types de stockage partagé pris en charge, reportez-vous à la section Formats de référentiel de stockage. Cette section montre comment le stockage partagé (représenté par un référentiel de stockage) peut être créé sur un serveur NFS existant.

Pour ajouter du stockage partagé NFS à un pool de ressources à l’aide de l’interface de ligne de commande

  1. Ouvrez une console sur n’importe quel hôte XenServer du pool.

  2. Créez le référentiel de stockage sur server :/path en exécutant la commande suivante :

      xe sr-create content-type=user type=nfs name-label="Example SR" shared=true \
          device-config:server=server \
          device-config:serverpath=path
    <!--NeedCopy-->
    

    configuration_périphérique :serveur est le nom d’hôte du serveur NFS et device-config :cheminserveur est le chemin d’accès sur le serveur NFS. Comme partagé est défini sur true, le stockage partagé est automatiquement connecté à chaque hôte XenServer du pool. Tous les hôtes XenServer qui rejoignent plus tard sont également connectés au stockage. L’identificateur unique universel (UUID) du référentiel de stockage s’affiche à l’écran.

  3. Trouvez l’UUID du pool en exécutant la commande suivante :

      xe pool-list
    <!--NeedCopy-->
    
  4. Définissez le stockage partagé comme stockage partagé par défaut à l’échelle du pool à l’aide de la commande suivante :

      xe pool-param-set uuid=pool_uuid default-SR=sr_uuid
    <!--NeedCopy-->
    

    Étant donné que le stockage partagé a été défini par défaut à l’échelle du pool, toutes les futures machines virtuelles ont leurs disques créés sur le stockage partagé par défaut. Pour plus d’informations sur la création d’autres types de stockage partagé, consultez Formats de référentiel de stockage.

Supprimer les hôtes XenServer d’un pool de ressources

Remarque :

Avant de supprimer un hôte XenServer d’un pool, assurez-vous d’arrêter toutes les machines virtuelles exécutées sur cet hôte. Sinon, vous pouvez voir un avertissement indiquant que l’hôte ne peut pas être supprimé.

Lorsque vous supprimez (éjecter) à partir d’un pool, la machine est redémarrée, réinitialisée et laissée dans un état similaire à celui d’une nouvelle installation. N’éjectez pas les hôtes XenServer d’un pool s’il y a des données importantes sur les disques locaux.

Pour supprimer un hôte d’un pool de ressources à l’aide de l’interface de ligne de commande

  1. Ouvrez une console sur n’importe quel hôte du pool.

  2. Trouvez l’UUID de l’hôte en exécutant la commande suivante :

      xe host-list
    <!--NeedCopy-->
    
  3. Éjectez l’hôte requis du pool :

      xe pool-eject host-uuid=host_uuid
    <!--NeedCopy-->
    

    L’hôte XenServer est éjecté et laissé dans un état fraîchement installé.

    Avertissement :

    Faire non Éjecter un hôte d’un pool de ressources s’il contient des données importantes stockées sur ses disques locaux. Toutes les données sont effacées lorsqu’un hôte est éjecté du pool. Si vous souhaitez conserver ces données, copiez la machine virtuelle dans le stockage partagé sur le pool à l’aide de XenCenter ou de la commande xe vm-copy CI.

Lorsque des hôtes XenServer contenant des machines virtuelles stockées localement sont éjectés d’un pool, les machines virtuelles sont présentes dans la base de données du pool. Les VM stockées localement sont également visibles par les autres hôtes XenServer. Les machines virtuelles ne démarrent pas tant que les disques virtuels qui leur sont associés n’ont pas été modifiés pour pointer vers le stockage partagé vu par d’autres hôtes XenServer du pool, ou supprimés. Par conséquent, nous vous recommandons de déplacer tout stockage local vers le stockage partagé lorsque vous rejoignez un pool. Le passage au stockage partagé permet d’éjecter (ou de faire échouer physiquement) des hôtes XenServer individuels sans perte de données.

Remarque :

Lorsqu’un hôte est supprimé d’un pool dont l’interface de gestion se trouve sur un réseau VLAN balisé, la machine est redémarrée et son interface de gestion est disponible sur le même réseau.

Préparer un pool d’hôtes XenServer pour la maintenance

Avant d’effectuer des opérations de maintenance sur un hôte qui fait partie d’un pool de ressources, vous devez le désactiver. La désactivation de l’hôte empêche le démarrage des machines virtuelles sur celui-ci. Vous devez ensuite migrer ses VM vers un autre hôte XenServer du pool. Pour ce faire, placez l’hôte XenServer en mode Maintenance à l’aide de XenCenter. Pour plus d’informations, consultez Exécuter en mode maintenance dans la documentation XenCenter.

La synchronisation des sauvegardes a lieu toutes les 24 heures. Le fait de placer le coordinateur de pool en mode maintenance entraîne la perte des dernières 24 heures de mises à jour RRD pour les machines virtuelles hors ligne.

Avertissement :

Nous vous recommandons vivement de redémarrer tous les hôtes XenServer avant d’installer une mise à jour, puis de vérifier leur configuration. Certaines modifications de configuration ne prennent effet que lorsque l’hôte XenServer est redémarré, de sorte que le redémarrage peut révéler des problèmes de configuration qui peuvent entraîner l’échec de la mise à jour.

Pour préparer un hôte d’un pool pour les opérations de maintenance à l’aide de l’interface de ligne de commande

  1. Exécutez la commande suivante :

      xe host-disable uuid=XenServer_host_uuid
      xe host-evacuate uuid=XenServer_host_uuid
    <!--NeedCopy-->
    

    Cette commande désactive l’hôte XenServer, puis migre toutes les machines virtuelles en cours d’exécution vers d’autres hôtes XenServer du pool.

  2. Effectuez l’opération de maintenance souhaitée.

  3. Activez l’hôte XenServer lorsque l’opération de maintenance est terminée :

      xe host-enable
    <!--NeedCopy-->
    
  4. Redémarrez toutes les machines virtuelles arrêtées et reprenez toutes les machines virtuelles suspendues.

Exporter les données du pool de ressources

L’option Exporter les données de ressource vous permet de générer un rapport de données de ressource pour votre pool et d’exporter le rapport dans un fichier .xls ou .csv. Ce rapport fournit des informations détaillées sur les différentes ressources du pool, telles que les hôtes, les réseaux, le stockage, les machines virtuelles, les VDI et les GPU. Cette fonctionnalité permet aux administrateurs de suivre, planifier et attribuer des ressources en fonction de diverses charges de travail telles que le processeur, le stockage et le réseau.

Remarque :

L’exportation des données du pool de ressources est disponible pour les clients XenServer Premium Edition.

La liste des ressources et les différents types de données de ressource qui sont inclus dans le rapport :

Serveur :

  • Nom
  • Coordonnateur de piscine
  • UUID
  • Adresse
  • Utilisation du processeur
  • Réseau (Ko moyens/max)
  • Mémoire utilisée
  • Stockage
  • Disponibilité
  • Description

Réseaux:

  • Nom
  • État du lien
  • MAC
  • MTU
  • VLAN
  • Type
  • Emplacement

VDI:

  • Nom
  • Type
  • UUID
  • Taille
  • Stockage
  • Description

Stockage :

  • Nom
  • Type
  • UUID
  • Taille
  • Emplacement
  • Description

Vms:

  • Nom
  • État d’alimentation
  • Continuer à courir
  • Adresse
  • MAC
  • Carte d’interface réseau
  • Système d’exploitation
  • Stockage
  • Mémoire utilisée
  • Utilisation du processeur
  • UUID
  • Disponibilité
  • Modèle
  • Description

Processeur graphique:

  • Nom
  • Serveurs
  • Chemin d’accès au bus PCI
  • UUID
  • Consommation d’énergie
  • Température
  • Mémoire utilisée
  • Utilisation de l’ordinateur

Remarque :

Les informations sur les GPU ne sont disponibles que si des GPU sont attachés à votre hôte XenServer.

Pour exporter des données de ressource

  1. Dans le volet de navigation XenCenter, sélectionnez Infrastructure , puis sélectionnez le pool.

  2. Sélectionnez l’icône Mare menu puis Exporter les données de ressources.

  3. Naviguez jusqu’à l’emplacement où vous souhaitez enregistrer le rapport, puis cliquez sur Sauvegarder.

Mise sous tension de l’hôte

Mise sous tension des hôtes à distance

Vous pouvez utiliser la fonctionnalité de mise sous tension de l’hôte XenServer pour allumer et éteindre un hôte à distance, soit à partir de XenCenter, soit à l’aide de l’interface de ligne de commande.

Pour activer l’alimentation de l’hôte, celui-ci doit disposer de l’une des solutions de contrôle de l’alimentation suivantes :

  • Wake on LAN : carte réseau compatible LAN.

  • Interface IPMI (Intelligent Platform Management Interface).

  • Script personnalisé basé sur l’API de gestion qui vous permet d’allumer et d’éteindre l’appareil via XenServer. Pour plus d’informations, consultez Configuration d’un script personnalisé pour la fonction de mise sous tension de l’hôte dans la section suivante.

L’utilisation de la fonction de mise sous tension de l’hôte nécessite deux tâches :

  1. Assurez-vous que les hôtes du pool prennent en charge le contrôle de l’alimentation à distance. Par exemple, ils disposent de la fonctionnalité Wake on LAN ou prennent en charge IPMI, ou vous avez créé un script personnalisé.

  2. Activez la fonctionnalité de mise sous tension de l’hôte à l’aide de l’interface de ligne de commande ou de XenCenter.

Utiliser l’interface de ligne de commande pour gérer la mise sous tension de l’hôte

Vous pouvez gérer la fonctionnalité de mise sous tension de l’hôte à l’aide de l’interface de ligne de commande ou de XenCenter. Cette section fournit des informations sur sa gestion avec l’interface de ligne de commande.

La mise sous tension de l’hôte est activée au niveau de l’hôte (c’est-à-dire sur chaque XenServer).

Après avoir activé la mise sous tension de l’hôte, vous pouvez activer les hôtes à l’aide de l’interface de ligne de commande ou de XenCenter.

Pour activer la mise sous tension de l’hôte à l’aide de l’interface de ligne de commande

Exécutez la commande :

  xe host-set-power-on-mode host=<host uuid> \
      power-on-mode=("" , "wake-on-lan", "IPMI","custom") \
      power-on-config=key:value
<!--NeedCopy-->

Pour activer des hôtes à distance à l’aide de l’interface de ligne de commande

Exécutez la commande :

  xe host-power-on host=<host uuid>
<!--NeedCopy-->

Configurer un script personnalisé pour la fonctionnalité de mise sous tension de l’hôte

Si la solution d’alimentation à distance de votre hôte utilise un protocole qui n’est pas pris en charge par défaut (tel que Wake-On-Ring ou Intel Active Management Technology), vous pouvez créer un script Linux Python 3 personnalisé pour allumer vos ordinateurs XenServer à distance. Toutefois, vous pouvez également créer des scripts personnalisés pour les solutions d’alimentation à distance IPMI et Wake on LAN.

Cette section fournit des informations sur la configuration d’un script personnalisé pour la mise sous tension de l’hôte à l’aide des paires clé/valeur associées à l’appel d’API XenServer host.power_on.

Lorsque vous créez un script personnalisé, exécutez-le à partir de la ligne de commande chaque fois que vous souhaitez contrôler l’alimentation à distance sur un hôte XenServer. Vous pouvez également le spécifier dans XenCenter et utiliser les fonctionnalités de l’interface utilisateur de XenCenter pour interagir avec lui.

L’API XenServer est documentée dans la section API de gestion XenServer.

Avertissement :

Ne modifiez pas les scripts fournis par défaut dans le /etc/xapi.d/plugins/ répertoire. Vous pouvez inclure de nouveaux scripts dans ce répertoire, mais vous ne devez jamais modifier les scripts contenus dans ce répertoire après l’installation.

Paires clé/valeur

Pour utiliser la mise sous tension de l’hôte, configurez le host.power_on_mode et host.power_on_config Clés. Pour plus d’informations sur les valeurs, reportez-vous à la section suivante.

Il existe également un appel d’API qui vous permet de définir ces champs simultanément :

  void host.set_host_power_on_mode(string mode, Dictionary<string,string> config)
<!--NeedCopy-->
host.power_on_mode
  • Définition: Contient des paires clé/valeur pour spécifier le type de solution d’alimentation à distance.

  • Valeurs possibles:

    • Chaîne vide, représentant le contrôle de l’alimentation désactivé.

    • « IPMI » : permet de spécifier l’interface de gestion intelligente de la plate-forme.

    • « wake-on-lan » : vous permet de spécifier Wake on LAN.

    • Tout autre nom (utilisé pour spécifier un script de mise sous tension personnalisé). Cette option permet de spécifier un script personnalisé pour la gestion de l’alimentation.

  • Type:corde

host.power_on_config
  • Définition: Contient des paires clé/valeur pour la configuration du mode. Fournit des informations supplémentaires sur IPMI.

  • Valeurs possibles :

    • Si vous avez configuré IPMI comme type de solution d’alimentation à distance, vous devez également spécifier l’une des clés suivantes :

      • « power_on_ip » : l’adresse IP que vous avez spécifiée et configurée pour communiquer avec la carte de contrôle de l’alimentation.

      • « power_on_user » : nom d’utilisateur IPMI associé au processeur de gestion, que vous avez peut-être modifié par rapport à ses paramètres d’usine par défaut.

      • « power_on_password_secret » : spécifie l’utilisation de la fonction secrets pour sécuriser votre mot de passe.

    • Pour utiliser la fonction secrets pour stocker votre mot de passe, spécifiez la clé « power_on_password_secret ». Pour plus d’informations, consultez Secrets.

  • Type: Carte (chaîne, chaîne)

Exemple de script

L’exemple de script importe l’API XenServer, se définit lui-même comme un script personnalisé, puis transmet les paramètres spécifiques à l’hôte que vous souhaitez contrôler à distance. Vous devez définir les paramètres session dans tous les scripts personnalisés.

Le résultat s’affiche lorsque le script échoue.

  import XenAPI
  def custom(session,remote_host,
  power_on_config):
  result="Power On Not Successful"
  for key in power_on_config.keys():
  result=result+''
  key=''+key+''
  value=''+power_on_config[key]
  return result
<!--NeedCopy-->

Remarque :

Après avoir créé le script, enregistrez-le dans /etc/xapi.d/plugins avec une extension .py.

Communiquer avec les hôtes XenServer et les pools de ressources

TLS

XenServer utilise le protocole TLS 1.2 pour chiffrer le trafic de l’API de gestion. Toute communication entre XenServer et les clients (ou appliances) de l’API de gestion utilise le protocole TLS 1.2.

Important :

Nous ne prenons pas en charge les modifications apportées par les clients à la fonctionnalité cryptographique du produit.

XenServer utilise la suite de chiffrement suivante :

  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256

SSH

Lors de l’utilisation d’un client SSH pour se connecter directement à l’hôte XenServer, les algorithmes suivants peuvent être utilisés :

Chiffrement:

Mac:

  • Référence : HMAC-SHA2-256
  • HMAC-SHA2-512
  • HMAC-SHA1

KexAlgorithms :

  • Courbe25519-SHA256
  • ECDH-SHA2-NISTP256
  • ECDH-SHA2-NISTP384
  • ECDH-SHA2-NISTP521
  • diffie-hellman-groupe14-sha1

HostKeyAlgorithms :

  • ECDSA-SHA2-NISTP256
  • ECDSA-SHA2-NISTP384
  • ECDSA-SHA2-NISTP521
  • ssh-ed25519
  • ssh-rsa

Si vous souhaitez désactiver l’accès SSH à votre hôte XenServer, vous pouvez le faire dans xsconsole.

  1. Depuis XenCenter, ouvrez la console hôte et connectez-vous en tant que racine.
  2. Type xsconsole.
  3. Dans xsconsoleAtteindre Configuration du service à distance > Activer/désactiver Remote Shell.

    La console indique si l’interpréteur de commandes distant est activé.

  4. Pour changer si le shell distant est activé ou désactivé, appuyez sur Entrer.

Important :

Nous ne prenons pas en charge les modifications apportées par les clients à la fonctionnalité cryptographique du produit.

Installer un certificat TLS sur votre hébergeur

L’hôte XenServer est installé avec un certificat TLS par défaut. Toutefois, pour utiliser HTTPS afin de sécuriser la communication entre XenServer et Citrix Virtual Apps and Desktops, installez un certificat fourni par une autorité de certification approuvée.

Cette section décrit comment installer des certificats à l’aide de l’interface de ligne de commande xe. Pour plus d’informations sur l’utilisation des certificats à l’aide de XenCenter, consultez la documentation XenCenter.

Assurez-vous que votre certificat TLS et sa clé répondent aux exigences suivantes :

  • Le certificat et la paire de clés sont des clés RSA.
  • La clé correspond au certificat.
  • La clé est fournie dans un fichier distinct du certificat.
  • Le certificat est fourni dans un fichier distinct de tous les certificats intermédiaires.
  • Le fichier de clé doit être de l’un des types suivants : .Pem ou .clé.
  • Tous les fichiers de certificat doivent être de l’un des types suivants : .Pem, .cerou .tube cathodique.
  • La clé est supérieure ou égale à 2048 bits et inférieure ou égale à 4096 bits.
  • Il s’agit d’une clé PKCS #8 non chiffrée et n’a pas de clé d’accès.
  • La clé et le certificat sont au format « PEM » encodé en base 64.
  • Le certificat est valide et n’a pas expiré.
  • L’algorithme de signature est SHA-2 (SHA256).

L’interface de ligne de commande xe vous avertit lorsque le certificat et la clé que vous choisissez ne répondent pas à ces exigences.

Où puis-je obtenir un certificat TLS ?

1. Générer une demande de signature de certificat

Tout d’abord, générez une demande de signature de clé privée et de certificat. Sur l’hôte XenServer, procédez comme suit :

  1. Pour créer un fichier de clé privée, exécutez la commande suivante :

      openssl genrsa -des3 -out privatekey.pem 2048
    <!--NeedCopy-->
    

    Vous êtes invité à saisir une phrase de passe. Cette phrase de passe est supprimée à l’étape suivante.

  2. Supprimez le mot de passe de la touche :

      openssl rsa -in privatekey.pem -out privatekey.nop.pem
    <!--NeedCopy-->
    
  3. Créez la demande de signature de certificat à l’aide de la clé privée :

      openssl req -new -key privatekey.nop.pem -out csr
    <!--NeedCopy-->
    
  4. Suivez les invites pour fournir les informations nécessaires à la génération de la demande de signature de certificat.

    • Nom du pays. Entrez les codes de pays du certificat TLS pour votre pays. Par exemple, CA pour le Canada ou JM pour la Jamaïque. Vous pouvez trouver une liste des codes de pays des certificats TLS sur le Web.
    • Nom de l’État ou de la province (nom complet). Entrez l’état ou la province où se trouve la piscine. Par exemple, le Massachusetts ou l’Alberta.
    • Nom de la localité. Le nom de la ville où se trouve la piscine.
    • Nom de l’organisation. Le nom de votre entreprise ou organisation.
    • Nom de l’unité organisationnelle. Entrez le nom du département. Ce champ est facultatif.
    • Nom commun. Entrez le nom de domaine complet de votre hôte XenServer. Nous vous recommandons de spécifier un nom de domaine complet ou une adresse IP qui n’expire pas.
    • Adresse courriel. Cette adresse e-mail est incluse dans le certificat lorsque vous le générez.

    La demande de signature de certificat est enregistrée dans le répertoire courant et est nommée Rse.

  5. Affichez la demande de signature de certificat dans la fenêtre de console en exécutant la commande suivante :

      cat csr
    <!--NeedCopy-->
    
  6. Copiez l’intégralité de la demande de signature de certificat et utilisez ces informations pour demander le certificat à l’autorité de certification.

    Exemple de demande de signature de certificat :

      -----BEGIN CERTIFICATE REQUEST-----
      MIIDBDCCAewCAQAwgYsxCzAJBgNVBAYTAlVLMRcwFQYDVQQIDA5DYW1icmlkZ2Vz
      aGlyZTESMBAGA1UEBwwJQ2FtYnJpZGdlMRIwEAYDVQQKDAlYZW5TZXJ2ZXIxFTAT
      ...
      SdYCkFdo+85z8hBULFzSH6jgSP0UGQU0PcfIy7KPKyI4jnFQqeCDvLdWyhtAx9gq
      Fu40qMSm1dNCFfnACRwYQkQgqCt/RHeUtl8srxyZC+odbunnV+ZyQdmLwLuQySUk
      ZL8naumG3yU=
      -----END CERTIFICATE REQUEST-----
    <!--NeedCopy-->
    

2. Envoyez la demande de signature de certificat à une autorité de certification

Maintenant que vous avez généré la demande de signature de certificat, vous pouvez l’envoyer à l’autorité de certification de votre organisation.

Une autorité de certification est un tiers de confiance qui fournit des certificats numériques. Certaines autorités de certification exigent que les certificats soient hébergés sur un système accessible à partir d’Internet. Nous vous recommandons de ne pas utiliser une autorité de certification avec cette exigence.

L’autorité de certification répond à votre demande de signature et fournit les fichiers suivants :

  • le certificat signé
  • le cas échéant, un certificat intermédiaire

Vous pouvez maintenant installer tous ces fichiers sur votre hébergeur XenServer.

3. Installez le certificat signé sur votre hôte XenServer

Une fois que l’autorité de certification a répondu à la demande de signature de certificat, procédez comme suit pour installer le certificat sur votre hôte XenServer :

  1. Obtenez le certificat signé et, si l’autorité de certification en possède un, le certificat intermédiaire auprès de l’autorité de certification.
  2. Copiez la clé et les certificats sur l’hôte XenServer.
  3. Exécutez la commande suivante sur l’hôte :

      xe host-server-certificate-install certificate=<path_to_certificate_file> private-key=<path_to_private_key> certificate-chain=<path_to_chain_file>
    

    Le chaîne-de-certificats est facultatif.

Pour plus de sécurité, vous pouvez supprimer le fichier de clé privée après l’installation du certificat.

Gérer le mot de passe administrateur

Lorsque vous installez pour la première fois un hôte XenServer, vous définissez un administrateur ou racine mot de passe. Vous utilisez ce mot de passe pour connecter XenCenter à votre hôte ou (avec votre nom d’utilisateur racine) pour vous connecter xsconsole, la console de configuration du système.

Si vous joignez un hôte à un pool, le mot de passe administrateur de l’hôte est automatiquement modifié pour correspondre au mot de passe administrateur du coordinateur de pool.

Remarque :

Les mots de passe administrateur XenServer ne doivent contenir que des caractères ASCII imprimables.

Modifier le mot de passe

Vous pouvez utiliser XenCenter, l’interface de ligne de commande xe ou xsconsole pour modifier le mot de passe administrateur.

XenCenter

Pour modifier le mot de passe administrateur d’un pool ou d’un hôte autonome à l’aide de XenCenter, procédez comme suit :

  1. Dans le Ressources , sélectionnez le pool ou n’importe quel hôte du pool.
  2. Sur le Mare ou sur le menu Serveur menu, sélectionnez Modifier le mot de passe du serveur.

Pour modifier le mot de passe racine d’un hôte autonome, sélectionnez l’hôte dans le Ressources , puis cliquez sur Mot de passe Et puis Changement de la Serveur menu.

Si XenCenter est configuré pour enregistrer vos identifiants de connexion d’hôte entre les sessions, le nouveau mot de passe est mémorisé. Pour plus d’informations, consultez Stocker l’état de votre connexion hôte.

Après avoir modifié le mot de passe administrateur, faites pivoter le secret du pool. Pour plus d’informations, consultez Rotation du secret de pool.

xe CLI

Pour modifier le mot de passe administrateur à l’aide de l’interface de ligne de commande xe, exécutez la commande suivante sur un hôte du pool :

    xe user-password-change new=<new_password>
<!--NeedCopy-->

Remarque :

Assurez-vous de faire précéder la commande d’un espace pour éviter de stocker le mot de passe en texte brut dans l’historique des commandes.

Après avoir modifié le mot de passe administrateur, faites pivoter le secret du pool. Pour plus d’informations, consultez Rotation du secret de pool.

xsconsole

Pour modifier le mot de passe administrateur d’un pool ou d’un hôte autonome à l’aide de xsconsole, procédez comme suit :

  1. Sur le coordinateur de piscine, accédez à la console.
  2. Connectez-vous en tant que racine.
  3. Type xsconsole. Presser Entrer. Le xsconsole s’affiche.
  4. Dans xsconsole, utilisez les touches fléchées pour accéder à l’icône Authentification option. Presser Entrer.
  5. Accédez à Changer le mot de passe. Presser Entrer.
  6. Authentifiez-vous avec le mot de passe administrateur.
  7. Dans le Changer le mot de passe dialogue:
    1. Entrez votre mot de passe actuel.
    2. Entrez un nouveau mot de passe.
    3. Entrez à nouveau le nouveau mot de passe pour le confirmer.

    Le Changement de mot de passe réussi s’affiche. Presser Entrer de rejeter.

Si l’hôte est le coordinateur du pool, ce mot de passe mis à jour est maintenant propagé aux autres hôtes du pool.

Après avoir modifié le mot de passe administrateur, faites pivoter le secret du pool. Pour plus d’informations, consultez Rotation du secret de pool.

Réinitialiser un mot de passe root perdu

Si vous perdez le mot de passe administrateur (root) de votre hôte XenServer, vous pouvez réinitialiser le mot de passe en accédant directement à l’hôte.

  1. Redémarrez l’hôte XenServer.

  2. Lorsque le menu GRUB s’affiche, appuyez sur e pour modifier l’entrée du menu de démarrage.

  3. Ajouter init=/sysroot/bin/sh à la ligne qui commence par Module2.

  4. Presser Ctrl-X pour démarrer dans un shell racine.

  5. Au niveau de l’interpréteur de commandes, exécutez les commandes suivantes :

      chroot /sysroot
      passwd
    
      (type the new password twice)
    
      sync
      /sbin/reboot -f
    <!--NeedCopy-->
    

Si l’hôte est le coordinateur du pool, ce mot de passe mis à jour est maintenant propagé aux autres hôtes du pool.

Après avoir modifié le mot de passe administrateur, faites pivoter le secret du pool.

Rotation du secret de pool

Le secret de pool est un secret partagé entre les hôtes d’un pool qui permet à l’hôte de prouver son appartenance à un pool.

Étant donné que les utilisateurs disposant du rôle Administrateur de pool peuvent découvrir ce secret, il est recommandé de faire pivoter le secret de pool si l’un de ces utilisateurs quitte votre organisation ou perd son rôle d’administrateur de pool.

Vous pouvez faire pivoter le secret de pool à l’aide de XenCenter ou de l’interface de ligne de commande xe.

XenCenter

Pour faire pivoter le secret de pool d’un pool à l’aide de XenCenter, procédez comme suit :

  1. Dans le Ressources , sélectionnez le pool ou n’importe quel hôte du pool.
  2. Sur le Mare menu, sélectionnez Rotation du secret de la piscine.

Lorsque vous effectuez la rotation du secret de pool, vous êtes également invité à modifier le mot de passe root. Si vous avez effectué une rotation du secret de pool parce que vous pensez que votre environnement a été compromis, assurez-vous de modifier également le mot de passe root. Pour plus d’informations, consultez Modifier le mot de passe.

xe CLI

Pour faire pivoter le secret de pool à l’aide de l’interface de ligne de commande xe, exécutez la commande suivante sur un hôte du pool :

  xe pool-secret-rotate
<!--NeedCopy-->

Si vous avez effectué une rotation du secret de pool parce que vous pensez que votre environnement a été compromis, assurez-vous de modifier également le mot de passe root. Pour plus d’informations, consultez Modifier le mot de passe.

Activer la surveillance IGMP sur votre pool XenServer

XenServer envoie du trafic de multidiffusion à toutes les machines virtuelles invitées, ce qui entraîne une charge inutile sur les périphériques hôtes en les obligeant à traiter des paquets qu’ils n’ont pas sollicités. L’activation de la surveillance IGMP empêche les hôtes d’un réseau local de recevoir le trafic d’un groupe de multidiffusion qu’ils n’ont pas explicitement rejoint et améliore les performances de la multidiffusion. La surveillance IGMP est particulièrement utile pour les applications de multidiffusion IP gourmandes en bande passante, telles que l’IPTV.

Remarques  :

  • La surveillance IGMP n’est disponible que lorsque le back-end réseau utilise Open vSwitch.

  • Lors de l’activation de cette fonctionnalité sur un pool, il peut également être nécessaire d’activer l’interrogation IGMP sur l’un des commutateurs physiques. Sinon, la multidiffusion dans le sous-réseau revient à la diffusion et peut diminuer les performances de XenServer.

  • Lors de l’activation de cette fonctionnalité sur un pool exécutant IGMP v3, la migration de machine virtuelle ou le basculement de liaison réseau entraîne le basculement de la version IGMP vers la version v2.

  • Pour activer cette fonctionnalité avec un réseau GRE, les utilisateurs doivent configurer un interrogateur IGMP dans le réseau GRE. Vous pouvez également transférer le message de requête IGMP du réseau physique vers le réseau GRE. Sinon, le trafic de multidiffusion dans le réseau GRE peut être bloqué.

Vous pouvez activer la surveillance IGMP sur un pool à l’aide de XenCenter ou de l’interface de ligne de commande xe.

XenCenter

  1. Accédez à Propriétés de la piscine.
  2. Choisir Options réseau. Ici, vous pouvez activer ou désactiver l’espionnage IGMP.

xe CLI

  1. Obtenez l’UUID de la piscine :

    xe pool-list

  2. Activez/désactivez la surveillance IGMP pour le pool :

    xe pool-param-set [uuid=pool-uuid] [igmp-snooping-enabled=true|false]

Après avoir activé la surveillance IGMP, vous pouvez afficher la table de surveillance IGMP à l’aide de l’interface de ligne de commande xe.

Voir le tableau de surveillance IGMP

Utilisez la commande suivante pour afficher la table de surveillance IGMP :

ovs-appctl mdb/show [bridge name]

Remarque :

Vous pouvez obtenir le nom du pont en utilisant xe network-list. Ces noms de pont peuvent être xenbr0, xenbr1, xenapiou xapi0.

Cela génère un tableau avec quatre colonnes :

  • port : port du commutateur (OVS).
  • VLAN : ID VLAN du trafic.
  • GROUP : groupe de multidiffusion sollicité par le port.
  • Age : L’âge de ce disque en secondes.

Si l’icône GROUPE est une adresse de groupe de multidiffusion, ce qui signifie qu’un message de rapport IGMP a été reçu sur le port de commutation associé. Cela signifie qu’un récepteur (membre) du groupe de multidiffusion écoute sur ce port.

Prenons l’exemple suivant qui contient deux enregistrements :

port VLAN GROUP Âge
14 0 227.0.0.1 15
1 0 Livreur 24

Le premier enregistrement montre qu’il y a un récepteur qui écoute sur le port 14 pour le groupe de multidiffusion 227.0.0.1. Open vSwitch transfère le trafic destiné au groupe de multidiffusion 227.0.0.1 vers les ports d’écoute de ce groupe uniquement (dans cet exemple, le port 14), plutôt que de diffuser vers tous les ports. L’enregistrement liant le port 14 et le groupe 227.0.0.1 a été créé il y a 15 secondes. Par défaut, l’intervalle de délai d’expiration est de 300 secondes. Cela signifie que si le commutateur ne reçoit plus de messages de rapport IGMP sur le port 14 pendant 300 secondes après l’ajout de l’enregistrement, l’enregistrement expire et est supprimé de la table.

Dans le deuxième enregistrement, le GROUPE est Livreur, ce qui signifie que des messages de requête IGMP ont été reçus sur le port associé. Une requête envoie périodiquement des messages de requête IGMP, qui sont diffusés à tous les ports de commutateur, afin de déterminer quels nœuds de réseau sont à l’écoute sur un groupe de multidiffusion. À la réception d’un message de requête IGMP, le récepteur répond par un message de rapport IGMP, ce qui entraîne l’actualisation de l’enregistrement de multidiffusion du récepteur et évite l’expiration.

Le VLAN indique au VLAN qu’un récepteur/interrogateur vit. « 0 » signifie VLAN natif. Si vous souhaitez exécuter la multidiffusion sur un VLAN balisé, assurez-vous qu’il y a des enregistrements sur le VLAN.

Remarque :

Pour le scénario VLAN, vous devez disposer d’un enregistrement de requête avec une valeur de colonne VLAN égale à l’ID VLAN du réseau, sinon la multidiffusion ne fonctionnera pas dans le réseau VLAN.

Activer la compression du flux de migration sur votre pool XenServer

Lors de la migration en direct d’une machine virtuelle, sa mémoire est transférée sous forme de flux de données entre deux hôtes utilisant le réseau. La fonctionnalité de compression du flux de migration compresse ce flux de données, accélérant ainsi le transfert de mémoire sur les réseaux lents. Cette fonctionnalité est désactivée par défaut, mais elle peut être modifiée à l’aide de XenCenter ou de l’interface de ligne de commande xe. Pour plus d’informations, consultez Propriétés de la piscine - Avancé et Paramètres de la piscine. Vous pouvez également activer la compression lors de la migration d’une machine virtuelle à l’aide de la ligne de commande. Pour plus d’informations, consultez la page vm-migrate commande dans Commandes VM.