Gérer vos pools

Cet article décrit certaines des actions que vous pouvez entreprendre pour gérer votre pool.

Pour gérer les hôtes individuels, consultez Gérer vos hôtes.

Créer 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, l’hôte rejoignant synchronise sa base de données locale avec celle du pool et hérite de certains paramètres du pool :

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

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

  • Les adresses IP des cartes réseau de gestion, qui sont conservées 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 du pool ont des interfaces de gestion sur une interface agrégée, l’hôte rejoignant doit être migré vers l’agrégat après avoir rejoint le pool.

  • Les cartes réseau de stockage dédiées, qui doivent être réaffectées à l’hôte rejoignant depuis XenCenter ou la CLI, et les 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 la carte réseau de stockage ne fonctionne que si elle est correctement configurée. Pour plus d’informations sur la façon de dédier une carte réseau de stockage à partir de la CLI, consultez Gérer la mise en réseau.

  • Reconfigurez l’interface de gestion et déplacez-la vers une carte réseau physique avant d’ajouter l’hôte au pool. Une fois l’hôte ajouté au pool, vous pouvez reconfigurer l’interface de gestion à nouveau.

Avant de créer un pool de ressources, examinez les exigences pour le pool et l’hôte rejoignant. Pour plus d’informations, consultez Pools de ressources.

Ajouter un hôte à un pool à l’aide de la CLI xe

1. Mettez à jour votre pool et l’hôte rejoignant au même niveau avant de tenter la jonction. Vous pouvez le faire de l’une des manières suivantes :

   • Mettez à jour l’hôte rejoignant au même niveau que le pool :

     • (Recommandé) En synchronisant l’hôte rejoignant avec le pool et en effectuant la mise à jour à partir des fichiers de mise à jour conservés sur le coordinateur de pool. Pour plus d’informations, consultez Mettre à jour au niveau du pool.
     • En téléchargeant un bundle de mise à jour qui correspond au niveau du pool et en l’utilisant pour mettre à jour l’hôte rejoignant.

   • Mettez à jour le pool et l’hôte rejoignant au dernier niveau :

     • En synchronisant l’hôte et le pool avec le même canal de mise à jour et en appliquant les dernières mises à jour.
     • En utilisant le mécanisme de mises à jour hors ligne pour appliquer le dernier niveau de mises à jour à l’hôte et au pool.

   Pour plus d’informations sur ces méthodes de mise à jour, consultez Appliquer les mises à jour à l’aide de XenCenter ou Appliquer les mises à jour à l’aide de l’interface de ligne de commande xe.

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

3. Joignez 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 master-address doit être défini sur le nom de domaine complet du coordinateur de pool. Le password doit être le 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 rejoignant est automatiquement modifié pour correspondre au mot de passe administrateur du coordinateur de pool.

Les hôtes XenServer appartiennent par défaut à un pool sans nom. Pour créer votre premier pool de ressources, renommez le pool sans nom existant. Utilisez la complétion par tabulation 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’extension des déploiements au fil du temps en permettant à du matériel hôte disparate d’être joint à 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 à l’utilisation de technologies dans les CPU Intel (FlexMigration) et AMD (Extended Migration) qui fournissent un « masquage » ou un « nivellement » du CPU. Les fonctionnalités de masquage et de nivellement du CPU permettent de configurer un CPU pour qu’il apparaisse comme offrant une marque, un modèle ou une fonctionnalité différente de ce qu’il est réellement. Cette fonctionnalité vous permet de créer des pools d’hôtes avec des CPU 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 être du même fournisseur (c’est-à-dire, AMD, Intel) que les processeurs des hôtes déjà présents dans le pool. Cependant, les hôtes ne sont pas obligés d’être 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. Les hôtes peuvent désormais être ajoutés à des pools de ressources existants, indépendamment du type de processeur sous-jacent (tant que le processeur provient de la même famille de fournisseurs). L’ensemble de 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 de l’ensemble de fonctionnalités du pool n’affecte pas les machines virtuelles qui sont actuellement en cours d’exécution 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 fixé au démarrage et persiste lors 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 hôte différent au sein ou entre des pools, XenServer compare l’ensemble de fonctionnalités de la machine virtuelle à l’ensemble de 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 au sein et entre les pools, quelles que soient les fonctionnalités CPU que la machine virtuelle utilise. Si vous utilisez l’équilibrage de charge (Workload Balancing) pour sélectionner un hôte de destination optimal pour migrer votre machine virtuelle, un hôte avec un ensemble de fonctionnalités incompatible ne sera pas recommandé comme hôte de destination.

Ajouter du stockage partagé

Cette section présente un exemple de la façon dont le stockage partagé (représenté comme un référentiel de stockage) peut être créé sur un serveur NFS existant. Pour une liste complète des types de stockage partagé pris en charge, consultez Stockage.

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

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

2. Créez le référentiel de stockage sur serveur:/chemin 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 est le chemin d’accès sur le serveur NFS. Comme shared est défini sur true, le stockage partagé est automatiquement connecté à chaque hôte XenServer du pool. Tout hôte XenServer qui rejoint ultérieurement est également connecté au stockage. L’identifiant unique universel (UUID) du référentiel de stockage est affiché à 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 valeur par défaut à l’échelle du pool avec la commande suivante :

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

   Comme le stockage partagé a été défini comme la valeur par défaut pour l’ensemble du pool, toutes les futures machines virtuelles auront 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 Créer un SR.

Supprimer des 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, un avertissement indiquant que l’hôte ne peut pas être supprimé peut s’afficher.

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 à 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 la CLI

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 :

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

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 un stockage partagé visible par les autres hôtes XenServer du pool, ou supprimés. Par conséquent, nous vous recommandons de déplacer tout stockage local vers un stockage partagé lors de l’intégration à un pool. Le déplacement vers un stockage partagé permet aux hôtes XenServer individuels d’être éjectés (ou de tomber en panne physique) 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 sera disponible sur le même réseau.

Renouveler 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 de pool peuvent découvrir ce secret, il est recommandé de renouveler le secret du pool si l’un de ces utilisateurs quitte votre organisation ou perd son rôle d’administrateur de pool.

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

XenCenter

Pour renouveler le secret du pool pour un pool à l’aide de XenCenter, suivez les étapes suivantes :

1. Dans le volet Ressources, sélectionnez le pool ou n’importe quel hôte du pool.
2. Dans le menu Pool, sélectionnez Renouveler le secret du pool.

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

xe CLI

Pour renouveler 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 renouvelé le secret du 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.

Configurer l’accès SSH

L’accès SSH à votre pool XenServer est activé par défaut. Si vous souhaitez désactiver l’accès SSH à votre pool XenServer, exécutez la commande suivante :

xe pool-disable-ssh pool=<pool_uuid_or_name_label>
<!--NeedCopy-->

Cette commande désactive SSH. Le pool refuse les nouvelles connexions SSH mais ne déconnecte aucune session existante.

Pour activer l’accès SSH à votre pool XenServer, exécutez la commande suivante :

xe pool-enable-ssh pool=<pool_uuid_or_name_label>
<!--NeedCopy-->

Pour définir le délai d’expiration temporaire (en secondes) de l’activation SSH du pool actuel :

xe pool-param-set uuid=<pool-uuid> ssh-enabled-timeout=<seconds>
<!--NeedCopy-->

Le paramètre de délai d’expiration détermine la durée du service SSH. Lorsqu’il est défini sur 0, SSH reste actif indéfiniment. Lorsqu’il est défini sur un entier positif (en secondes), SSH est automatiquement désactivé après la période spécifiée. Les modifications de configuration prennent effet immédiatement sur les sessions SSH actives suivantes et à chaque fois que l’utilisateur active SSH.

Remarque :

La valeur maximale que vous pouvez définir pour ssh-enabled-timeout est de 172800 secondes (soit environ 2 jours).

Pour définir le délai d’expiration d’inactivité de la console SSH du pool actuel (en secondes)

xe pool-param-set uuid=<pool-uuid> console-idle-timeout=<seconds>
<!--NeedCopy-->

Configurez le délai d’expiration des sessions inactives pour les connexions de console VNC et SSH en utilisant une valeur entière non négative en secondes, où 0 désactive le délai d’expiration (les sessions n’expirent jamais) et les valeurs positives (par exemple, 3600) terminent automatiquement les sessions inactives après la durée spécifiée, les paramètres s’appliquant aux sessions de console nouvellement créées après la configuration.

Pour définir le mode automatique SSH du pool actuel

xe poolparam-set uuid=<pool-uuid>  ssh-auto-mode=true
<!--NeedCopy-->

Configurez la gestion automatique de SSH en fonction de l’état de santé du service XAPI. Lorsque le mode automatique est activé, l’activation de SSH suit l’état de XAPI : SSH est désactivé lorsque XAPI est sain et activé lorsque XAPI est malsain.

Mode automatique activé + ssh_enabled_timeout = 0 : L’activation manuelle de SSH via pool.enable_ssh désactive définitivement le mode automatique.

Mode automatique activé + ssh_enabled_timeout > 0 : L’activation manuelle de SSH désactive temporairement le mode automatique ; le mode automatique est restauré au paramètre d’origine lorsque le délai d’expiration expire. (Lorsqu’un redémarrage du système se produit pendant une période de délai d’expiration SSH active, le paramètre de mode automatique d’origine est perdu et est réinitialisé à activé lors de l’expiration/récupération.)

Pour la valeur du paramètre de pool dans l’une ou l’autre de ces commandes, vous pouvez utiliser un sélecteur de pool. Pour plus d’informations, consultez Commandes de pool.

Vous pouvez gérer l’accès SSH pour tous les pools d’un pool XenServer en même temps. Pour plus d’informations, consultez Désactiver l’accès SSH pour un pool.

Comportement de jonction / éjection de pool

• Jonction – Lorsqu’un serveur rejoint un pool, les paramètres SSH (délai d’expiration SSH activé, délai d’expiration de la console inactive, mode automatique) sont hérités.

• Éjecter – Lorsqu’un serveur est éjecté d’un pool, les paramètres par défaut sont restaurés.

  • XenServer 8.4 : SSH activé, mode automatique désactivé

Définition du nouveau contrôle de gestion SSH

Définissez la nouvelle API XAPI pool.set_ssh_auto_mode au niveau du pool pour configurer SSH

set_ssh_auto_mode : Configurez pour activer ou désactiver le mode automatique SSH. Lorsque le mode automatique est activé, l’état de SSH dépend de l’état de XAPI : SSH est désactivé lorsque XAPI est sain, et SSH est activé lorsque XAPI est malsain.

Lorsqu’un utilisateur active le mode automatique et que le ssh_enabled_timeout actuel est 0, l’activation de SSH avec pool.enable_ssh désactivera définitivement le mode automatique.

Lorsqu’un utilisateur définit le mode automatique avec pool.set_auto_mode comme activé ou désactivé, cela est appelé le « paramètre de mode automatique d’origine ». Si le ssh_enabled_timeout actuel est défini sur un nombre positif (par exemple, 1800 secondes), l’activation de SSH avec pool.enable_ssh désactivera temporairement le mode automatique. Lorsque la période de temporisation expire, SSH sera automatiquement désactivé et le mode automatique sera restauré à son paramètre d’origine.

Lorsqu’un utilisateur définit ssh_enabled_timeout sur un nombre positif (par exemple, 3600 secondes) et redémarre l’hôte (ou redémarre XAPI) avant l’expiration de la période de temporisation, une fois cette période expirée, SSH sera automatiquement désactivé et le mode automatique sera restauré à « vrai », car le redémarrage aura entraîné la perte du paramètre de mode automatique d’origine.

Lorsque vous configurez ssh_enabled_timeout sur un nombre positif (par exemple, 180 secondes) et que XAPI échoue par la suite, si XAPI reste dans un état d’échec lorsque la période de temporisation expire, SSH restera activé jusqu’à ce que XAPI redémarre. Au redémarrage de XAPI, SSH sera automatiquement désactivé et le mode automatique sera restauré à « vrai », car le redémarrage du système entraîne la perte du paramètre de mode automatique d’origine.

This command disables SSH. The hosts refuse new SSH connections, but do not disconnect any existing sessions.

To enable SSH access to all hosts in your pool, run the following command:

xe pool-enable-ssh ```

Both of these commands attempt to make a change on all hosts in the pool. If the command fails on one or more of the hosts in your pool, the command continues to run for all other hosts in the pool. The command returns a list of any hosts where the command fails.

You can manage the SSH access for an individual host. For more information, see Disable SSH access for a host.–>

Activer l’IGMP snooping sur votre pool XenServer

XenServer envoie le 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 l’IGMP snooping 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 adhéré, et améliore les performances de la multidiffusion. L’IGMP snooping est particulièrement utile pour les applications de multidiffusion IP gourmandes en bande passante, telles que l’IPTV.

Remarques :

• Lors de l’activation de cette fonctionnalité sur un pool, il peut également être nécessaire d’activer le querier 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.

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

• Pour activer cette fonctionnalité avec un réseau GRE, les utilisateurs doivent configurer un Querier IGMP dans le réseau GRE. Alternativement, vous pouvez 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 l’espionnage IGMP sur un pool à l’aide de XenCenter ou de l’interface de ligne de commande xe.

XenCenter

1. Accédez à Propriétés du pool.
2. Sélectionnez Options réseau. Ici, vous pouvez activer ou désactiver l’espionnage IGMP.

xe CLI

1. Obtenez l’UUID du pool :

   xe pool-list

2. Activer/désactiver l’espionnage IGMP pour le pool :

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

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

Afficher la table d’espionnage IGMP

Utilisez la commande suivante pour afficher la table d’espionnage 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, xenapi ou xapi0.

Ceci affiche un tableau à quatre colonnes :

• port : Le port du commutateur (OVS).
• VLAN : L’ID VLAN du trafic.
• GROUP : Le groupe de multidiffusion que le port a sollicité.
• Age : L’âge de cet enregistrement en secondes.

Si le GROUP est une adresse de groupe de multidiffusion, cela signifie qu’un message de rapport IGMP est reçu sur le port de commutateur associé. Cela signifie qu’un récepteur (membre) du groupe de multidiffusion écoute sur ce port.

Prenez l’exemple suivant qui contient deux enregistrements :

Le premier enregistrement indique qu’il y a un récepteur à l’écoute sur le port 14 pour le groupe de multidiffusion 227.0.0.1. L’Open vSwitch transmet le trafic destiné au groupe de multidiffusion 227.0.0.1 uniquement aux ports d’écoute de ce groupe (dans cet exemple, le port 14), plutôt que de le diffuser à 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 plus de messages 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 deuxième enregistrement, le GROUPE est querier, ce qui signifie que des messages de requête IGMP ont été reçus sur le port associé. Un querier envoie périodiquement des messages de requête IGMP, qui sont diffusés à tous les ports du commutateur, pour déterminer quels nœuds du réseau sont à l’écoute sur un groupe de multidiffusion. Dès 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 le VLAN où se trouve un récepteur/querier. ‘0’ signifie VLAN natif. Si vous souhaitez exécuter la multidiffusion sur un VLAN balisé, assurez-vous qu’il existe des enregistrements sur ce VLAN.

Note :

Pour le scénario VLAN, vous devez avoir un enregistrement de querier avec une valeur de colonne VLAN égale à l’ID de 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 via 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 fonction est désactivée par défaut, mais cela peut être modifié à 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. Alternativement, vous pouvez activer la compression lors de la migration d’une machine virtuelle en utilisant la ligne de commande. Pour plus d’informations, consultez la commande vm-migrate dans Commandes de machine virtuelle.

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 ce rapport dans un fichier .xls ou .csv. Ce rapport fournit des informations détaillées sur diverses ressources du pool telles que les hôtes, les réseaux, le stockage, les machines virtuelles, les VDI et les GPU. Cette fonction permet aux administrateurs de suivre, planifier et attribuer des ressources en fonction de diverses charges de travail telles que le CPU, le stockage et le réseau.

Note :

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 de ressource inclus dans le rapport :

Serveur :

• Nom
• Coordinateur de pool
• UUID
• Adresse
• Utilisation du CPU
• Réseau (moy/max Ko)
• Mémoire utilisée
• Stockage
• Temps de fonctionnement
• 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 d’alimentation
• Exécution sur
• Adresse
• MAC
• NIC
• Système d’exploitation
• Stockage
• Mémoire utilisée
• Utilisation du CPU
• UUID
• Durée de fonctionnement
• Modèle
• Description

GPU :

• Nom
• Serveurs
• Chemin du bus PCI
• UUID
• Consommation électrique
• Température
• Mémoire utilisée
• Utilisation du système

Remarque :

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

Pour exporter les données de ressource

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 à un emplacement où vous souhaitez enregistrer le rapport, puis cliquez sur Enregistrer.