Citrix Hypervisor

Hôtes et pools de ressources

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

Vue d’ensemble des serveurs et des pools de ressources Citrix Hypervisor

Un pool de ressources comprend plusieurs installations de serveurs Citrix Hypervisor, 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 sur n’importe quel serveur Citrix Hypervisor disposant d’une mémoire suffisante. Les machines virtuelles peuvent ensuite être déplacées dynamiquement entre les serveurs Citrix Hypervisor tout en fonctionnant avec un temps d’arrêt minimal (migration en direct). Si un serveur Citrix Hypervisor subit une défaillance matérielle, l’administrateur peut redémarrer les machines virtuelles défaillantes sur un autre serveur Citrix Hypervisor du même pool de ressources. Lorsque la haute disponibilité est activée sur le pool de ressources, les machines virtuelles se déplacent automatiquement 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 possède toujours au moins un nœud physique, appelé maître. Seul le nœud maître expose une interface d’administration (utilisée par XenCenter et l’interface de ligne de commande de Citrix Hypervisor, connue sous le nom de xe CLI). Le maître transmet les commandes aux membres individuels si nécessaire.

Remarque :

Lorsque le maître de pool échoue, la réélection du maître n’a lieu que si la haute disponibilité est activée.

Conditions requises pour créer des pools de ressources

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

  • Les processeurs sur le serveur reliant le pool sont les mêmes (en termes de fournisseur, de modèle et de fonctionnalités) que les processeurs sur les serveurs déjà présents dans le pool.

  • Le serveur qui rejoint le pool exécute la même version du logiciel Citrix Hypervisor, au même niveau de correctif, que les serveurs déjà présents dans le pool.

Le logiciel impose des contraintes supplémentaires lors de la connexion d’un serveur à un pool. Citrix Hypervisor vérifie notamment que les conditions suivantes sont remplies pour le serveur qui rejoint le pool :

  • Le serveur n’est pas membre d’un pool de ressources existant.

  • Aucun stockage partagé n’est configuré sur le serveur.

  • Le serveur 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 du serveur, comme l’arrêt d’une machine virtuelle.

  • L’horloge du serveur est synchronisée en même temps que celle du maître du pool (par exemple, en utilisant NTP).

  • L’interface de gestion du serveur n’est pas liée. Vous pouvez configurer l’interface de gestion lorsque le serveur rejoint le pool avec succès.

  • L’adresse IP de gestion est statique, soit configurée sur le serveur lui-même, soit en utilisant une configuration appropriée sur votre serveur DHCP.

Les serveurs Citrix Hypervisor dans les pools de ressources peuvent contenir un nombre différent d’interfaces réseau physiques et disposer de référentiels de stockage locaux de taille variable. Dans la pratique, il est souvent difficile d’obtenir plusieurs serveurs avec exactement les mêmes processeurs, et des variations mineures sont donc autorisées. S’il est acceptable d’avoir des hôtes avec différents processeurs dans le même pool, vous pouvez forcer l’opération d’adhésion au pool en transmettant le paramètre --force.

Tous les hôtes du pool doivent se trouver dans 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 avoir une adresse IP statique.

Un pool doit contenir des référentiels de stockage partagés pour sélectionner le serveur Citrix Hypervisor sur lequel exécuter une machine virtuelle et déplacer dynamiquement une machine virtuelle entre les serveurs Citrix Hypervisor. 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 un stockage local vers un stockage partagé après avoir ajouté du stockage partagé. Vous pouvez utiliser la commande xe vm-copy ou utiliser XenCenter pour déplacer des machines virtuelles.

Création d’un pool de ressources

Les pools de ressources peuvent être créés à l’aide de XenCenter ou de la CLI. Lorsqu’un nouvel hôte rejoint un pool de ressources, il synchronise sa base de données locale avec celle de l’ensemble 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 une fois que l’hôte a rejoint le pool.

  • L’hôte qui rejoint hérite des référentiels de stockage partagé 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 : les détails structurels des cartes réseau, des VLAN et des interfaces liées sont tous hérités, mais pas les informations de stratégie . Ces informations de stratégie, qui doivent être reconfigurées, incluent :

    • Les adresses IP des cartes réseau de gestion, qui sont conservées par rapport à 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 du 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 jointure.

    • Les cartes réseau de stockage dédiées, qui doivent être réaffectées à l’hôte rejoignant à partir de XenCenter ou de l’interface de ligne de commande, et les PBD rebranchés pour acheminer le trafic en conséquence. Cela est dû au fait que les adresses IP ne sont pas affectées dans le cadre de l’opération de jointure de pool et que la carte réseau de stockage ne fonctionne que lorsque celle-ci 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, consultez Gérer le réseau

Remarque :

Vous ne pouvez joindre un nouvel hôte à un pool de ressources que lorsque 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

  1. Ouvrez une console sur l’hôte Citrix Hypervisor que vous souhaitez rejoindre à un pool.

  2. Joignez l’hôte Citrix Hypervisor au pool en exécutant la commande suivante :

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

    La master-address doit être définie sur le nom de domaine complet du coordinateur du pool. password doit être le mot de passe administrateur défini lors de l’installation du coordinateur du pool.

Remarque :

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

Les serveurs Citrix Hypervisor appartiennent par défaut à un pool non nommé. Pour créer votre premier pool de ressources, renommez le pool sans nom existant. Utilisez tab-complete pour trouver pool_uuid :

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

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

Citrix Hypervisor simplifie les déploiements étendus au fil du temps en permettant de joindre du matériel hôte disparate à un pool de ressources, connu sous le nom de pools de ressources hétérogènes. Les pools de ressources hétérogènes sont rendus possibles grâce aux technologies des processeurs Intel (FlexMigration) et AMD (Extended Migration) qui fournissent un « masquage » ou un « nivellement » du processeur. Les fonctionnalités de masquage et de mise à niveau du processeur permettent de configurer un processeur pour qu’il apparaisse comme fournissant une marque, un modèle ou une fonctionnalité différents de ce qu’il est réellement. Cette fonctionnalité vous permet de créer des pools d’hôtes avec des processeurs disparates tout en prenant en charge la migration en direct en toute sécurité.

Remarque :

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

Citrix Hypervisor simplifie la prise en charge de pools hétérogènes. Les hôtes peuvent désormais être ajoutés aux pools de ressources existants, quel que soit le type de processeur sous-jacent (tant que le processeur appartient à la même famille de fournisseurs). L’ensemble des fonctionnalités du pool est calculé dynamiquement à chaque fois :

  • Un nouvel hôte rejoint le pool

  • Un membre du pool quitte le pool

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

Toute modification apportée à l’ensemble des 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 lors des opérations de migration, de suspension et de reprise. Si le niveau du pool baisse 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 ou entre des pools, Citrix Hypervisor 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 jugés compatibles, la machine virtuelle est autorisée à migrer. Cela permet à la machine virtuelle de se déplacer librement à l’intérieur et entre les pools, quelles que soient les fonctionnalités du processeur que la machine virtuelle utilise. Si vous utilisez l’équilibrage de la charge de travail pour sélectionner un hôte de destination optimal pour migrer votre machine virtuelle, un hôte avec un ensemble de fonctionnalités incompatibles ne sera pas recommandé comme hôte de destination.

Ajouter un stockage partagé

Pour obtenir la liste complète des types de stockage partagé pris en charge, consultez la section Formats de référentiel de stockage. Cette section montre comment le stockage partagé (représenté comme 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 serveur Citrix Hypervisor du pool.

  2. Créez le référentiel de stockage sur le serveur : /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-->
    

    device-config:server Nom d’hôte du serveur NFS et chemin device-config:serverpath d’accès sur le serveur NFS. Comme shared il est défini sur true, le stockage partagé est automatiquement connecté à chaque serveur Citrix Hypervisor du pool. Tous les serveurs Citrix Hypervisor qui se joignent ultérieurement sont également connectés au stockage. L’identifiant unique universel (UUID) du référentiel de stockage est imprimé à l’écran.

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

    xe pool-list
    <!--NeedCopy-->
    
  4. Définissez le stockage partagé comme stockage 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-->
    

    Comme le stockage partagé a été défini comme valeur par défaut à l’échelle du pool, les disques de toutes les futures machines virtuelles ont été 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 serveurs Citrix Hypervisor d’un pool de ressources

Remarque :

Avant de supprimer un serveur Citrix Hypervisor 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 (éjectez) un hôte 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 serveurs Citrix Hypervisor d’un pool s’il existe 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. Recherchez 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-->
    

    Le serveur Citrix Hypervisor est éjecté et laissé dans un état fraîchement installé.

    Avertissement :

    N’éjectez pas 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 sur le stockage partagé du pool à l’aide de XenCenter ou de la commande xe vm-copy CLI.

Lorsque des serveurs Citrix Hypervisor 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 machines virtuelles stockées localement sont également visibles par les autres serveurs Citrix Hypervisor. 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 un stockage partagé vu par d’autres serveurs Citrix Hypervisor du pool, ou supprimés. Par conséquent, nous vous recommandons de déplacer tout stockage local vers un stockage partagé lorsque vous rejoignez un pool. Le passage au stockage partagé permet aux serveurs Citrix Hypervisor individuels d’être éjectés (ou de tomber en panne physiquement) 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 de serveurs Citrix Hypervisor pour la maintenance

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

La synchronisation de sauvegarde a lieu toutes les 24 heures. Le fait de placer l’hôte maître 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 serveurs Citrix Hypervisor avant d’installer une mise à jour, puis de vérifier leur configuration. Certaines modifications de configuration ne prennent effet que lorsque le serveur Citrix Hypervisor est redémarré, de sorte que le redémarrage peut révéler des problèmes de configuration pouvant entraîner l’échec de la mise à jour.

Pour préparer un hôte dans 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=Citrix Hypervisor_host_uuid
    xe host-evacuate uuid=Citrix Hypervisor_host_uuid
    <!--NeedCopy-->
    

    Cette commande désactive le serveur Citrix Hypervisor, puis migre toutes les machines virtuelles en cours d’exécution vers d’autres serveurs Citrix Hypervisor du pool.

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

  3. Activez le serveur Citrix Hypervisor 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 ressources vous permet de générer un rapport de données de ressources pour votre pool et d’exporter le rapport dans un fichier .xls ou .csv. Ce rapport fournit des informations détaillées sur diverses ressources du pool telles que les serveurs, les réseaux, le stockage, les machines virtuelles, les VDI et les GPU. Cette fonctionnalité permet aux administrateurs de suivre, planifier et affecter 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 Citrix Hypervisor Premium Edition, ou ceux qui ont accès à Citrix Hypervisor via leur droit Citrix Virtual Apps and Desktops ou Citrix DaaS.

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

Serveur :

  • Nom
  • Maître du pool
  • UUID
  • Adresse
  • Utilisation du processeur
  • Réseau (kBs moyen/max)
  • Mémoire utilisée
  • Stockage
  • Temps d’activité
  • 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

VM :

  • Nom
  • État de l’alimentation
  • Exécuté sur
  • Adresse
  • MAC
  • Carte d’interface réseau
  • Système d’exploitation
  • Stockage
  • Mémoire utilisée
  • Utilisation du processeur
  • UUID
  • Temps d’activité
  • Modèle
  • Description

GPU :

  • Nom
  • Serveurs
  • Chemin du 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 connectés à votre serveur Citrix Hypervisor.

Pour exporter les données de ressources

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

  2. Sélectionnez le menu Pool, puis Exporter les données de ressource .

  3. Accédez à l’emplacement où vous souhaitez enregistrer le rapport, puis cliquez sur Enregistrer.

Démarrage de l’hôte

Mise sous tension des hôtes à distance

Vous pouvez utiliser la fonctionnalité de mise sous tension du serveur Citrix Hypervisor pour activer et désactiver un serveur à distance, soit à partir de XenCenter, soit à l’aide de l’interface de ligne de commande.

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

  • Carte réseau compatible Wake on LAN.

  • Cartes d’accès à distance Dell (DRAC). Pour utiliser Citrix Hypervisor avec DRAC, vous devez installer le pack supplémentaire Dell pour bénéficier du support DRAC. La prise en charge de DRAC nécessite l’installation de l’utilitaire de ligne de commande RACADM sur le serveur avec le contrôleur d’accès à distance et l’activation de DRAC et de son interface. RACADM est souvent inclus dans le logiciel de gestion DRAC. Pour plus d’informations, consultez la documentation DRAC de Dell.

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

L’utilisation de la fonction Host Power On 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 d’une carte DRAC, 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 la CLI 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 Citrix Hypervisor).

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 des hôtes à l’aide de l’interface

Exécutez la commande :

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

Pour DRAC, les clés consistent power_on_ip à spécifier le mot de passe si vous utilisez la fonction secrète. Pour plus d’informations, consultez Secrets.

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

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

Si la solution d’alimentation à distance de votre serveur 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 Python Linux personnalisé pour allumer vos ordinateurs Citrix Hypervisor à distance. Toutefois, vous pouvez également créer des scripts personnalisés pour les solutions d’alimentation à distance DRAC et Wake on LAN.

Cette section fournit des informations sur la configuration d’un script personnalisé pour Host Power On à l’aide des paires clé/valeur associées à l’appel API Citrix Hypervisor 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 serveur Citrix Hypervisor. Vous pouvez également le spécifier dans XenCenter et utiliser les fonctionnalités de l’interface utilisateur XenCenter pour interagir avec elle.

L’API Citrix Hypervisor est documentée dans le document, l’API de gestion Citrix Hypervisor, disponible sur le site Web de documentation du développeur .

Avertissement :

Ne modifiez pas les scripts fournis par défaut dans le répertoire /etc/xapi.d/plugins/. 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 Host Power On, configurez les touches host.power_on_mode et host.power_on_config. Consultez la section suivante pour plus d’informations sur les valeurs.

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 (par exemple, Dell DRAC).

  • Valeurs possibles :

    • Chaîne vide, représentant la commande d’alimentation désactivée.

    • « DRAC » : vous permet de spécifier Dell DRAC. Pour utiliser DRAC, vous devez déjà avoir installé le pack supplémentaire Dell.

    • « Wake-on-LAN » : 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 : chaîne

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

  • Valeurs possibles :

    • Si vous avez configuré la carte DRAC 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 configurée pour communiquer avec la carte de contrôle d’alimentation. Vous pouvez également saisir le nom de domaine de l’interface réseau sur laquelle la carte DRAC est configurée.

      • « power_on_user » : nom d’utilisateur DRAC 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 fonctionnalité 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 Citrix Hypervisor, se définit comme un script personnalisé, puis transmet des 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 l’extension .py.

Communiquez avec les serveurs et les pools de ressources Citrix Hypervisor

TLS

Citrix Hypervisor utilise le protocole TLS 1.2 pour chiffrer le trafic de l’API de gestion. Toute communication entre Citrix Hypervisor et les clients de l’API de gestion (ou les appliances) 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.

Citrix Hypervisor utilise la suite de chiffrement suivante :

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

En outre, les suites de chiffrement suivantes sont également prises en charge pour assurer la rétrocompatibilité avec certaines versions de Citrix Virtual Apps and Desktops :

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256

Remarque :

Ces suites de chiffrement supplémentaires utilisent le mode CBC. Bien que certaines organisations préfèrent le mode GCM, Windows Server 2012 R2 ne prend pas en charge les suites de chiffrement RSA avec le mode GCM. Les clients exécutant Windows Server 2012 R2 qui se connectent à un serveur ou à un pool Citrix Hypervisor peuvent avoir besoin d’utiliser ces suites de chiffrement en mode CBC.

SSH

Lorsque vous utilisez un client SSH pour vous connecter directement au serveur Citrix Hypervisor, les algorithmes suivants peuvent être utilisés :

Chiffrements :

  • aes128-ctr
  • aes256-ctr
  • aes128-gcm@openssh.com
  • aes256-gcm@openssh.com
  • aes128-cbc
  • aes256-cbc

MACs:

  • hmac-sha2-256
  • hmac-sha2-512
  • hmac-sha1

KexAlgorithms:

  • curve25519-sha256
  • ecdh-sha2-nistp256
  • ecdh-sha2-nistp384
  • ecdh-sha2-nistp521
  • diffie-hellman-group14-sha1

HostKeyAlgorithms:

  • ecdsa-sha2-nistp256
  • ecdsa-sha2-nistp384
  • ecdsa-sha2-nistp521
  • ssh-ed25519
  • SSH-RSA

Remarque :

Pour limiter les suites de chiffrement disponibles à celles de la liste précédente, assurez-vous d’installer le correctif XS82E015 - Pour Citrix Hypervisor 8.2.

Si vous souhaitez désactiver l’accès SSH à votre serveur Citrix Hypervisor, vous pouvez le faire dans xsconsole.

  1. À partir de XenCenter, ouvrez la console du serveur et connectez-vous en tant que root.
  2. Tapez xsconsole.
  3. Dans xsconsole, accédez à Configuration du service à distance > Activer/désactiver l’interpréteur de commandes à distance.

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

  4. Pour modifier si le shell distant est activé ou désactivé, appuyez sur Entrée.

Important :

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

Installez un certificat TLS sur votre serveur

Le serveur Citrix Hypervisor est installé avec un certificat TLS par défaut. Toutefois, pour utiliser HTTPS pour sécuriser la communication entre Citrix Hypervisor 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 séparé de tous les certificats intermédiaires.
  • Le fichier clé doit être de l’un des types suivants : .pem ou .key.
  • Tous les fichiers de certificat doivent être de l’un des types suivants : .pem, .cer ou .crt.
  • La clé est supérieure ou égale à 2 048 bits et d’une longueur inférieure ou égale à 4 096 bits.
  • La clé est une clé PKCS #8 non cryptée et ne possède pas de clé d’accès.
  • La clé et le certificat sont au format « PEM » codé 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érez une demande de signature de certificat

Commencez par générer une clé privée et une demande de signature de certificat. Sur le serveur Citrix Hypervisor, 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-->
    
  2. Supprimez le mot de passe de la clé :

    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 instructions pour fournir les informations nécessaires à la génération de la demande de signature de certificat.

    • Nom du pays. Entrez les codes pays du certificat TLS de votre pays. Par exemple, CA pour le Canada ou JM pour la Jamaïque. Vous pouvez trouver une liste des codes pays du certificat TLS sur le Web.
    • Nom del’État ou de la province (nom complet). Entrez l’État ou la province où se trouve le pool. Par exemple, le Massachusetts ou l’Alberta.
    • Nom de la localité. Le nom de la ville où se trouve le pool.
    • Nom de l’organisation. Le nom de votre entreprise ou organisation.
    • Nom de l’unité organisationnelle. Saisissez le nom du département. Ce champ est facultatif.
    • Nom commun. Entrez le nom de domaine complet de votre serveur Citrix Hypervisor. Citrix recommande de spécifier un nom de domaine complet ou une adresse IP qui n’expire pas.
    • Adresse e-mail. 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 en cours et est nommée csr.

  5. Affichez la demande de signature de certificat dans la fenêtre de la 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. Envoyer la demande de signature du certificat à une autorité de certification

Maintenant que vous avez généré la demande de signature de certificat, vous pouvez la soumettre à l’autorité de certification préférée 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 depuis Internet. Nous vous recommandons de ne pas faire appel à une autorité de certification ayant cette exigence.

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

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

Vous pouvez désormais installer tous ces fichiers sur votre serveur Citrix Hypervisor.

3. Installez le certificat signé sur votre serveur Citrix Hypervisor

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 serveur Citrix Hypervisor :

  1. Obtenez le certificat signé, le certificat racine 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 le serveur Citrix Hypervisor.
  3. Exécutez la commande suivante sur le serveur :

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

    Le paramètre certificate-chain 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 un serveur Citrix Hypervisor pour la première fois, vous définissez un mot de passe administrateur ou root . Vous utilisez ce mot de passe pour connecter XenCenter à votre serveur ou (avec le nom d’utilisateur root) pour vous connecter à xsconsole, la console de configuration du système.

Si vous joignez un serveur à un pool, le mot de passe administrateur du serveur est automatiquement modifié pour correspondre au mot de passe administrateur du pool maître.

Remarque :

Les mots de passe de l’administrateur Citrix Hypervisor ne doivent contenir que des caractères ASCII.

Changer 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 serveur autonome à l’aide de XenCenter, procédez comme suit :

  1. Dans le volet Ressources, sélectionnez le pool ou l’un des serveurs du pool.
  2. Dans le menu Pool ou dans le menu Serveur, sélectionnez Modifier le mot de passe du serveur.

Pour modifier le mot de passe racine d’un serveur autonome, sélectionnez le serveur dans le volet Ressources, puis cliquez sur Mot de passe, puis sur Modifier dans le menu Serveur .

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

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

CLI xe

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

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

Remarque :

Veillez à préfixer la commande par un espace pour éviter de stocker le mot de passe en clair 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 la section Rotation du secret de pool.

xsconsole

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

  1. Sur le pool master, accédez à la console.
  2. Connectez-vous en tant que root.
  3. Tapez xsconsole. Appuyez sur Entrée. La console xsconsole s’affiche.
  4. Dans xsconsole, utilisez les touches fléchées pour accéder à l’option Authentification . Appuyez sur Entrée.
  5. Accédez à Modifier le mot de passe. Appuyez sur Entrée.
  6. Authentifiez-vous avec le mot de passe administrateur.
  7. Dans la boîte de dialogue Change Password  :
    1. Saisissez votre mot de passe actuel.
    2. Saisissez un nouveau mot de passe.
    3. Saisissez à nouveau le nouveau mot de passe pour le confirmer.

    L’écran Changement de mot de passe réussi s’affiche. Appuyez sur Entrée pour fermer.

Si le serveur est maître du pool, ce mot de passe mis à jour est désormais propagé aux autres serveurs du pool.

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

Réinitialisation d’un mot de passe root perdu

Si vous perdez le mot de passe administrateur (root) de votre serveur Citrix Hypervisor, vous pouvez le réinitialiser en accédant directement au serveur.

  1. Redémarrez le serveur Citrix Hypervisor.

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

  3. Ajoutez init=/sysroot/bin/sh à la ligne qui commence par module2.

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

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

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

Si le serveur est maître du pool, ce mot de passe mis à jour est désormais propagé aux autres serveurs du pool.

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

Faites pivoter le secret du pool

Le secret du pool est un secret partagé entre les serveurs d’un pool qui permet au serveur de prouver son appartenance à un pool.

Étant donné que les utilisateurs ayant le rôle d’administrateur du pool peuvent découvrir ce secret, il est conseillé de modifier le secret du 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 la xe CLI.

XenCenter

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

  1. Dans le volet Ressources, sélectionnez le pool ou l’un des serveurs du pool.
  2. Dans le menu Pool, sélectionnez Rotation du secret de pool.

Lorsque vous permutez le 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.

CLI xe

Pour faire pivoter le secret de pool à l’aide de l’interface de ligne de commande xe, exécutez la commande suivante sur un serveur 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 l’espionnage IGMP sur votre pool Citrix Hypervisor

Citrix Hypervisor envoie du trafic de multidiffusion à toutes les machines virtuelles invitées, ce qui entraîne une charge inutile sur les machines hôtes en leur demandant de traiter des paquets qu’elles n’ont pas sollicités. L’activation de la surveillance IGMP empêche les hôtes d’un réseau local de recevoir du trafic pour un groupe de multidiffusion auquel 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 du réseau utilise Open vSwitch.

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

  • Lorsque vous activez cette fonctionnalité sur un pool exécutant IGMP v3, la migration de VM ou le basculement de liaison réseau entraîne le basculement de la version IGMP vers v2.

  • Pour activer cette fonctionnalité avec un réseau GRE, les utilisateurs doivent configurer un Querier IGMP sur 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 aux propriétés du pool.
  2. Sélectionnez Options réseau. Ici, vous pouvez activer ou désactiver la surveillance IGMP.

CLI xe

  1. Obtenez l’UUID du pool :

    xe pool-list

  2. Activer/désactiver 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.

Afficher le tableau d’espionnage 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 ponts peuvent être xenbr0xenbr1, xenapi, ou xapi0.

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

  • port : port du commutateur (OVS).
  • VLAN : ID VLAN du trafic.
  • GROUPE : groupe de multidiffusion sollicité par le port.
  • Âge : âge de cet enregistrement en secondes.

Si le GROUPE est une adresse de groupe de multidiffusion, cela signifie qu’un message de rapport IGMP a été reçu sur le port de commutateur 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 GROUPE Âge
14 0 227.0.0.1 15
1 0 interrogateur 24

Le premier enregistrement montre qu’un récepteur écoute le groupe de multidiffusion 227.0.0.1 sur le port 14. L’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 le 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 temporisation est de 300 secondes. Cela signifie que si le commutateur ne reçoit aucun autre message de rapport IGMP sur le port 14 pendant 300 secondes après l’ajout de l’enregistrement, celui-ci expire et est supprimé de la table.

Dans le second enregistrement, le GROUP est un objet de requête, ce qui signifie que des messages de requête IGMP ont été reçus sur le port associé. Un interrogateur envoie régulièrement des messages de requête IGMP, qui sont diffusés sur tous les ports du commutateur, afin de déterminer quels nœuds du réseau écoutent 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 son expiration.

La colonne VLAN indique au VLAN qu’un récepteur/demandeur est actif. « 0 » signifie un VLAN natif. Si vous souhaitez exécuter la multidiffusion sur un VLAN balisé, assurez-vous qu’il existe 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 sur le réseau VLAN.