layout: doc description: Create resource pools to group your XenServer hosts and shared storage into a single managed entity.—
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.
Un pool de ressources comprend plusieurs installations hôtes XenServer, liées entre elles à une seule entité gérée qui peut héberger des machines virtuelles. Associé à un stockage partagé, un pool de ressources permet de démarrer des machines virtuelles sur n’importe quel hôte XenServer disposant de suffisamment de mémoire. Les machines virtuelles peuvent ensuite être déplacées dynamiquement entre les hôtes XenServer tout en s’exécutant 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 défaillantes 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 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, connu sous le nom de coordinateur du pool (anciennement « maître du pool »). 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 de XE CLI). Le coordinateur transmet les commandes aux membres individuels si nécessaire.
Remarque :
Lorsque le coordinateur du pool échoue, la réélection du coordinateur n’a lieu que si la haute disponibilité est activée.
Un pool de ressources est un agrégat homogène (ou hétérogène avec restrictions) d’un ou de 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à présents dans le pool.
L’hôte rejoignant le pool exécute la même version du logiciel XenServer, au même niveau de correctif, que les hôtes déjà présents dans le pool.
Le logiciel impose des contraintes supplémentaires lors de l’adhésion d’un hôte à un pool. XenServer vérifie notamment que les conditions suivantes sont remplies pour que l’hôte rejoigne 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, comme l’arrêt d’une machine virtuelle.
L’horloge de l’hôte est synchronisée à la même heure que celle du coordinateur du pool (par exemple, à l’aide du protocole 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 avec succès.
L’adresse IP de gestion est statique, soit configurée sur l’hôte lui-même, soit en utilisant une configuration appropriée sur votre serveur DHCP.
Les hôtes XenServer des pools de ressources peuvent contenir différents nombres d’interfaces réseau physiques et disposer de référentiels de stockage locaux de tailles variables. Dans la pratique, il est souvent difficile d’obtenir plusieurs hôtes dotés exactement des mêmes processeurs, de sorte que des variations mineures sont 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 l’hôte XenServer sur lequel exécuter une machine virtuelle et pour déplacer dynamiquement une machine virtuelle entre les hôtes XenServer. 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.
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.
Remarque :
Nous vous recommandons de mettre à jour votre pool et l’hôte adhérent au même niveau avant de tenter la jointure.
Ouvrez une console sur l’hôte XenServer que vous souhaitez rejoindre à un pool.
Joignez l’hôte XenServer 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 hôtes XenServer appartiennent par défaut à un pool anonyme. 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-->
XenServer simplifie l’extension des déploiements 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 hôtes XenServer rejoignant des pools hétérogènes doivent être du même fournisseur (c’est-à-dire AMD, Intel) que les processeurs des hôtes déjà présents dans le pool. Cependant, il n’est pas nécessaire que les hôtes soient du même type au niveau de la famille, du modèle ou du numéro d’étape.
XenServer 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, XenServer compare l’ensemble des fonctionnalités de la machine virtuelle à celui 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.
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.
Ouvrez une console sur n’importe quel hôte XenServer du pool.
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 est le nom d’hôte du serveur NFS et device-config:serverpath le chemin sur le serveur NFS. Lorsqu’ shared il est défini sur true, le stockage partagé est automatiquement connecté à chaque hôte XenServer du pool. Tous les hôtes XenServer 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.
Recherchez l’UUID du pool en exécutant la commande suivante :
xe pool-list
<!--NeedCopy-->
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.
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 (é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 hôtes XenServer d’un pool si des données importantes se trouvent sur les disques locaux.
Ouvrez une console sur n’importe quel hôte du pool.
Recherchez l’UUID de l’hôte en exécutant la commande suivante :
xe host-list
<!--NeedCopy-->
É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 :
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-copyCLI.
Lorsque des hôtes XenServer contenant des machines virtuelles stockées localement sont éjectés d’un pool, les machines virtuelles seront présentes dans la base de données du pool. Les machines virtuelles 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 les autres hôtes XenServer du pool, ou qu’ils n’ont pas été 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 à des hôtes XenServer 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.
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 hôte XenServer du pool. Vous pouvez le faire en plaçant l’hôte XenServer 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 le coordinateur du 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é. Le redémarrage peut donc révéler des problèmes de configuration susceptibles d’entraîner l’échec de la mise à jour.
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.
Effectuez l’opération de maintenance souhaitée.
Activez l’hôte XenServer lorsque l’opération de maintenance est terminée :
xe host-enable
<!--NeedCopy-->
Redémarrez toutes les machines virtuelles arrêtées et reprenez toutes les machines virtuelles suspendues.
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 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, de planifier et d’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 de XenServer Premium Edition.
La liste des ressources et des différents types de données sur les ressources qui sont inclus dans le rapport :
Serveur :
Réseaux :
VDI :
Stockage :
VM :
GPU :
Remarque :
Les informations sur les GPU ne sont disponibles que si des GPU sont connectés à votre hôte XenServer.
Dans le volet de navigation XenCenter, sélectionnez Infrastructure, puis sélectionnez le pool.
Sélectionnez le menu Pool, puis Exporter les données de ressource .
Accédez à l’emplacement où vous souhaitez enregistrer le rapport, puis cliquez sur Enregistrer.
Vous pouvez utiliser la fonctionnalité XenServer Host Power On pour activer et éteindre un hôte à distance, soit depuis 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 XenServer avec DRAC, vous devez installer le pack supplémentaire Dell pour bénéficier du support DRAC. La prise en charge du DRAC nécessite l’installation de l’utilitaire de ligne de commande RACADM sur l’hôte doté du contrôleur d’accès à distance et l’activation du 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.
Un script personnalisé basé sur l’API de gestion qui vous permet d’activer et de désactiver l’alimentation via XenServer. 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 :
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é.
Activez la fonctionnalité de mise sous tension de l’hôte à l’aide de l’interface de ligne de commande ou de XenCenter.
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.
Host Power On est activé 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.
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.
Exécutez la commande :
xe host-power-on host=<host uuid>
<!--NeedCopy-->
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 Python Linux personnalisé pour allumer vos ordinateurs XenServer à 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 d’API XenServer. host.power_on
Lorsque vous créez un script personnalisé, exécutez-le depuis 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 XenCenter pour interagir avec elle.
L’API XenServer est documentée dans l’API de gestion XenServer.
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.
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-->
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
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)
L’exemple de script importe l’API XenServer, 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.
XenServer utilise le protocole TLS 1.2 pour chiffrer le trafic des API de gestion. Toute communication entre XenServer et les clients (ou appareils) d’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 :
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 :
Lorsque vous utilisez un client SSH pour vous connecter directement à l’hôte XenServer, les algorithmes suivants peuvent être utilisés :
Chiffrements :
MACs:
KexAlgorithms:
HostKeyAlgorithms:
Si vous souhaitez désactiver l’accès SSH à votre hôte XenServer, vous pouvez le faire dans. xsconsole
root
xsconsole.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é.
Important :
Nous ne prenons pas en charge les modifications apportées par les clients à la fonctionnalité cryptographique du produit.
L’hôte XenServer est installé avec un certificat TLS par défaut. Toutefois, pour utiliser le protocole HTTPS afin de sécuriser les communications 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 :
.pem ou .key..pem, .cer ou .crt.L’interface de ligne de commande xe vous avertit lorsque le certificat et la clé que vous choisissez ne répondent pas à ces exigences.
Vous pouvez également créer un certificat sur votre serveur et l’envoyer à l’autorité de certification de votre choix pour qu’il le signe. Cette méthode est plus sécurisée car la clé privée peut rester sur l’hôte XenServer et ne pas être copiée entre les systèmes.
La création d’un certificat TLS comprend les étapes suivantes :
Commencez par générer une clé privée et une demande de signature de certificat. Sur l’hôte XenServer, effectuez les étapes suivantes :
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 un mot de passe. Cette phrase secrète est supprimée lors de l’étape suivante.
Supprimez le mot de passe de la clé :
openssl rsa -in privatekey.pem -out privatekey.nop.pem
<!--NeedCopy-->
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-->
Suivez les instructions pour fournir les informations nécessaires à la génération de la demande de signature de certificat.
La demande de signature de certificat est enregistrée dans le répertoire en cours et est nommée csr.
Affichez la demande de signature de certificat dans la fenêtre de la console en exécutant la commande suivante :
cat csr
<!--NeedCopy-->
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-->
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 :
Vous pouvez désormais installer tous ces fichiers sur votre hôte XenServer.
Une fois que l’autorité de certification a répondu à la demande de signature du certificat, procédez comme suit pour installer le certificat sur votre hôte XenServer :
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 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.
Lorsque vous installez un hôte XenServer 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 hôte ou (avec votre rootnom d’utilisateur) 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 du pool.
Remarque :
Les mots de passe d’administrateur XenServer ne doivent contenir que des caractères ASCII.
Vous pouvez utiliser XenCenter, l’interface de ligne de commande xe ou xsconsole pour modifier le mot de passe administrateur.
Pour modifier le mot de passe administrateur d’un pool ou d’un hôte autonome à l’aide de XenCenter, procédez comme suit :
Pour modifier le mot de passe root d’un hôte autonome, sélectionnez l’hôte 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 de connexion d’hôte entre les sessions, le nouveau mot de passe est mémorisé. Pour plus d’informations, voir Enregistrer 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 la section Rotation du secret de pool.
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 :
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.
Pour modifier le mot de passe administrateur d’un pool ou d’un hôte autonome à l’aide de xsconsole, procédez comme suit :
root.xsconsole. Appuyez sur Entrée. La console xsconsole s’affiche.L’écran Changement de mot de passe réussi s’affiche. Appuyez sur Entrée pour fermer.
Si l’hôte est le coordinateur du pool, ce mot de passe mis à jour est désormais 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 la section Rotation du secret de pool.
Si vous perdez le mot de passe administrateur (root) de votre hôte XenServer, vous pouvez le réinitialiser en accédant directement à l’hôte.
Redémarrez l’hôte XenServer.
Lorsque le menu GRUB s’affiche, appuyez sur e pour modifier l’entrée du menu de démarrage.
Ajoutez init=/sysroot/bin/sh à la ligne qui commence par module2.
Appuyez sur Ctrl-X pour démarrer dans un shell racine.
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 l’hôte est le coordinateur du pool, ce mot de passe mis à jour est désormais propagé aux autres hôtes du pool.
Après avoir modifié le mot de passe administrateur, faites pivoter le secret du pool.
Le secret du 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 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.
Pour alterner le secret de pool d’un pool à l’aide de XenCenter, procédez comme suit :
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.
Pour faire pivoter le secret du 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.
XenServer envoie du trafic de multidiffusion à toutes les machines virtuelles clientes, ce qui entraîne une charge inutile sur les appareils 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 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 XenServer.
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.
Obtenez l’UUID du pool :
xe pool-list
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.
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 êtrexenbr0xenbr1,xenapi, ouxapi0.
Cela génère un tableau à quatre colonnes :
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.
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 fonction 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 du pool - Avancé et Paramètres du pool. 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 commande vm-migrate dans Commandes de machine virtuelle.