Administrar sus pools

Este artículo describe algunas de las acciones que puede realizar para administrar su pool.

Para administrar hosts individuales, consulte Administrar sus hosts.

Crear un pool de recursos

Los pools de recursos se pueden crear usando XenCenter® o la CLI. Cuando un nuevo host se une a un pool de recursos, el host que se une sincroniza su base de datos local con la del pool y hereda algunas configuraciones del pool:

• La configuración de almacenamiento de VM, local y remoto se añade a la base de datos de todo el pool. Esta configuración se aplica al host que se une al pool a menos que explícitamente haga que los recursos se compartan después de que el host se una al pool.

• El host que se une hereda los repositorios de almacenamiento compartido existentes en el pool. Se crean los registros PBD apropiados para que el nuevo host pueda acceder automáticamente al almacenamiento compartido existente.

• La información de red se hereda parcialmente al host que se une: los detalles estructurales de las NIC, VLAN y las interfaces enlazadas se heredan, pero la información de política no. Esta información de política, que debe reconfigurarse, incluye:

  • Las direcciones IP de las NIC de administración, que se conservan de la configuración original.

  • La ubicación de la interfaz de administración, que permanece igual que la configuración original. Por ejemplo, si los otros hosts del pool tienen interfaces de administración en una interfaz enlazada, el host que se une debe migrarse al enlace después de unirse.

  • Las NIC de almacenamiento dedicadas, que deben reasignarse al host que se une desde XenCenter o la CLI, y los PBD deben volverse a conectar para enrutar el tráfico en consecuencia. Esto se debe a que las direcciones IP no se asignan como parte de la operación de unión al pool, y la NIC de almacenamiento solo funciona cuando esto está configurado correctamente. Para obtener más información sobre cómo dedicar una NIC de almacenamiento desde la CLI, consulte Administrar redes.

  • Reconfigure la interfaz de administración y muévala a una NIC física antes de añadir el host al pool. Después de que el host se haya unido al pool, puede volver a configurar la interfaz de administración.

Antes de crear un pool de recursos, revise los requisitos para el pool y el host que se une. Para obtener más información, consulte Pools de recursos.

Añadir un host a un pool usando la CLI de xe

1. Actualice su pool y el host que se une al mismo nivel antes de intentar la unión. Puede hacerlo de una de las siguientes maneras:

   • Actualice el host que se va a unir al mismo nivel que el grupo:

     • (Recomendado) Sincronizando el host que se va a unir con el grupo y actualizando a partir de los archivos de actualización que se encuentran en el coordinador del grupo. Para obtener más información, consulte Actualizar al nivel del grupo.
     • Descargando un paquete de actualización que coincida con el nivel del grupo y usándolo para actualizar el host que se va a unir.

   • Actualice tanto el grupo como el host que se va a unir al nivel más reciente:

     • Sincronizando el host y el grupo con el mismo canal de actualización y aplicando las últimas actualizaciones.
     • Mediante el mecanismo de actualizaciones sin conexión para aplicar el nivel más reciente de actualizaciones tanto al host como al grupo.

   Para obtener más información sobre estos métodos de actualización, consulte Aplicar actualizaciones mediante XenCenter o Aplicar actualizaciones mediante la CLI de xe.

2. Abra una consola en el host XenServer® que desea unir a un grupo.

3. Una el host XenServer al grupo emitiendo el comando:

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

   master-address debe establecerse en el nombre de dominio completo del coordinador del grupo. password debe ser la contraseña de administrador establecida cuando se instaló el coordinador del grupo.

Nota:

Cuando se une un host a un grupo, la contraseña de administrador del host que se une se cambia automáticamente para que coincida con la contraseña de administrador del coordinador del grupo.

Los hosts XenServer pertenecen a un grupo sin nombre de forma predeterminada. Para crear su primer grupo de recursos, cambie el nombre del grupo sin nombre existente. Use la función de autocompletar con tabulador para encontrar el pool_uuid:

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

Crear grupos de recursos heterogéneos

XenServer simplifica la expansión de las implementaciones a lo largo del tiempo al permitir que hardware de host dispar se una a un grupo de recursos, conocidos como grupos de recursos heterogéneos. Los grupos de recursos heterogéneos son posibles gracias al uso de tecnologías en las CPU Intel (FlexMigration) y AMD (Extended Migration) que proporcionan “enmascaramiento” o “nivelación” de CPU. Las funciones de enmascaramiento y nivelación de CPU permiten configurar una CPU para que parezca que proporciona una marca, modelo o funcionalidad diferente de la que realmente tiene. Esta función le permite crear grupos de hosts con CPU dispares, pero que aún admiten de forma segura la migración en vivo.

Nota:

Las CPU de los hosts de XenServer que se unen a pools heterogéneos deben ser del mismo proveedor (es decir, AMD, Intel) que las CPU de los hosts que ya están en el pool. Sin embargo, no es necesario que los hosts sean del mismo tipo a nivel de familia, modelo o números de paso.

XenServer simplifica la compatibilidad con pools heterogéneos. Ahora se pueden agregar hosts a pools de recursos existentes, independientemente del tipo de CPU subyacente (siempre que la CPU sea de la misma familia de proveedores). El conjunto de funciones del pool se calcula dinámicamente cada vez que:

• Un nuevo host se une al pool

• Un miembro del pool abandona el pool

• Un miembro del pool se vuelve a conectar después de un reinicio

Cualquier cambio en el conjunto de funciones del pool no afecta a las máquinas virtuales que se están ejecutando actualmente en el pool. Una máquina virtual en ejecución continúa utilizando el conjunto de funciones que se aplicó cuando se inició. Este conjunto de funciones se fija en el arranque y persiste durante las operaciones de migración, suspensión y reanudación. Si el nivel del pool disminuye cuando un host menos capaz se une al pool, una máquina virtual en ejecución se puede migrar a cualquier host del pool, excepto al host recién agregado. Cuando mueve o migra una máquina virtual a un host diferente dentro o entre pools, XenServer compara el conjunto de funciones de la máquina virtual con el conjunto de funciones del host de destino. Si se determina que los conjuntos de funciones son compatibles, se permite la migración de la máquina virtual. Esto permite que la máquina virtual se mueva libremente dentro y entre pools, independientemente de las funciones de CPU que esté utilizando la máquina virtual. Si utiliza el equilibrio de carga de trabajo para seleccionar un host de destino óptimo para migrar su máquina virtual, no se recomendará un host con un conjunto de funciones incompatible como host de destino.

Agregar almacenamiento compartido

Esta sección muestra un ejemplo de cómo se puede crear almacenamiento compartido (representado como un repositorio de almacenamiento) en un servidor NFS existente. Para obtener una lista completa de los tipos de almacenamiento compartido admitidos, consulte Almacenamiento.

Para agregar almacenamiento compartido NFS a un pool de recursos mediante la CLI

1. Abra una consola en cualquier host de XenServer del pool.

2. Cree el repositorio de almacenamiento en server:/path emitiendo el siguiente comando:

   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 es el nombre de host del servidor NFS y device-config:serverpath es la ruta en el servidor NFS. Como shared está establecido en true, el almacenamiento compartido se conecta automáticamente a todos los hosts de XenServer del pool. Cualquier host de XenServer que se una más tarde también se conecta al almacenamiento. El identificador único universal (UUID) del repositorio de almacenamiento se imprime en la pantalla.

3. Busque el UUID del pool ejecutando el siguiente comando:

   xe pool-list
   <!--NeedCopy-->
   

4. Establezca el almacenamiento compartido como predeterminado para todo el pool con el siguiente comando:

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

   Como el almacenamiento compartido se ha establecido como predeterminado para todo el pool, todas las VM futuras tendrán sus discos creados en el almacenamiento compartido de forma predeterminada. Para obtener información sobre cómo crear otros tipos de almacenamiento compartido, consulte Crear un SR.

Eliminar hosts de XenServer de un pool de recursos

Nota:

Antes de eliminar cualquier host de XenServer de un pool, asegúrese de apagar todas las VM que se ejecutan en ese host. De lo contrario, puede aparecer una advertencia indicando que el host no se puede eliminar.

Cuando se elimina (expulsa) un host de un pool, la máquina se reinicia, se reinicializa y se deja en un estado similar a una instalación nueva. No expulse los hosts de XenServer de un pool si hay datos importantes en los discos locales.

Para eliminar un host de un pool de recursos mediante la CLI

1. Abra una consola en cualquier host del pool.

2. Busque el UUID del host ejecutando el siguiente comando:

   xe host-list
   <!--NeedCopy-->
   

3. Expulse el host requerido del pool:

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

   El host de XenServer se expulsa y se deja en un estado recién instalado.

   Advertencia:

   No expulse un host de un pool de recursos si contiene datos importantes almacenados en sus discos locales. Todos los datos se borran cuando se expulsa un host del pool. Si desea conservar estos datos, copie la VM en el almacenamiento compartido del pool mediante XenCenter o el comando CLI xe vm-copy.

Cuando los hosts de XenServer que contienen VM almacenadas localmente se expulsan de un pool, las VM estarán presentes en la base de datos del pool. Las VM almacenadas localmente también son visibles para los otros hosts de XenServer. Las VM no se inician hasta que los discos virtuales asociados a ellas se hayan cambiado para que apunten al almacenamiento compartido visto por otros hosts de XenServer en el pool, o se hayan eliminado. Por lo tanto, le recomendamos que mueva cualquier almacenamiento local a almacenamiento compartido al unirse a un pool. Moverse a almacenamiento compartido permite que los hosts de XenServer individuales sean expulsados (o fallen físicamente) sin pérdida de datos.

Nota:

Cuando se elimina un host de un pool que tiene su interfaz de administración en una red VLAN etiquetada, la máquina se reinicia y su interfaz de administración estará disponible en la misma red.

Rotar el secreto del pool

El secreto del pool es un secreto compartido entre los hosts de un pool que permite al host probar su pertenencia a un pool.

Dado que los usuarios con el rol de Administrador del pool pueden descubrir este secreto, es una buena práctica rotar el secreto del pool si uno de estos usuarios abandona su organización o pierde su rol de Administrador del pool.

Puede rotar el secreto del pool usando XenCenter o la CLI de xe.

XenCenter

Para rotar el secreto del pool de un pool usando XenCenter, complete los siguientes pasos:

1. En el panel de Recursos, seleccione el pool o cualquier host del pool.
2. En el menú Pool, seleccione Rotar secreto del pool.

Cuando rota el secreto del pool, también se le pide que cambie la contraseña de root. Si rotó el secreto del pool porque cree que su entorno ha sido comprometido, asegúrese de cambiar también la contraseña de root del coordinador del pool. Para obtener más información, consulte Cambiar la contraseña.

CLI de xe

Para rotar el secreto del pool usando la CLI de xe, ejecute el siguiente comando en un host del pool:

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

Si rotó el secreto del pool porque cree que su entorno ha sido comprometido, asegúrese de cambiar también la contraseña de root. Para obtener más información, consulte Cambiar la contraseña.

Configurar el acceso SSH

El acceso SSH a su pool de XenServer está habilitado de forma predeterminada. Si desea deshabilitar el acceso SSH a su pool de XenServer, ejecute el siguiente comando:

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

Este comando deshabilita SSH. El pool rechaza las nuevas conexiones SSH, pero no desconectar ninguna sesión existente.

Para habilitar el acceso SSH a su pool de XenServer, ejecute el siguiente comando:

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

Para establecer el tiempo de espera de habilitación temporal de SSH del pool actual (segundos):

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

El parámetro de tiempo de espera determina la duración del servicio SSH. Cuando se establece en 0, SSH permanece activo indefinidamente. Cuando se establece en un entero positivo (segundos), SSH se deshabilita automáticamente después del período especificado. Los cambios de configuración tienen efecto inmediato en las sesiones SSH activas posteriores y cada vez que el usuario habilita SSH.

Nota:

El valor máximo que puede establecer para ssh-enabled-timeout es de 172800 segundos (lo que equivale aproximadamente a 2 días).

Para establecer el tiempo de espera de inactividad de la consola SSH del pool actual (segundos)

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

Configure el tiempo de espera de inactividad de la sesión para las conexiones de consola VNC y SSH utilizando un valor entero no negativo en segundos, donde 0 deshabilita el tiempo de espera (las sesiones nunca caducan) y los valores positivos (por ejemplo, 3600) terminan automáticamente las sesiones inactivas después de la duración especificada, con la configuración aplicándose a las sesiones de consola recién creadas después de la configuración.

Para establecer el modo automático de SSH del pool actual

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

Configure la gestión automática de SSH basada en el estado de salud del servicio XAPI. Cuando el modo automático está habilitado, la activación de SSH sigue el estado de XAPI: SSH se deshabilita cuando XAPI está en buen estado y se habilita cuando XAPI no está en buen estado.

Modo automático habilitado + ssh_enabled_timeout = 0: La activación manual de SSH a través de pool.enable_ssh deshabilita permanentemente el modo automático.

Modo automático habilitado + ssh_enabled_timeout > 0: La activación manual de SSH deshabilita temporalmente el modo automático; el modo automático se restaura a la configuración original cuando expira el tiempo de espera. (Cuando se produce un reinicio del sistema durante un período de tiempo de espera de SSH activo, la configuración original del modo automático se pierde y se restablece a habilitado al expirar el tiempo de espera/recuperación).

Para el valor del parámetro del pool en cualquiera de estos comandos, puede usar un selector de pool. Para obtener más información, consulte Comandos de pool.

Puede administrar el acceso SSH para todos los pools en un pool de XenServer al mismo tiempo. Para obtener más información, consulte Deshabilitar el acceso SSH para un pool.

Comportamiento de unión / expulsión de pool

• Unión – Cuando un servidor se une a un pool, se heredan las configuraciones de SSH (tiempo de espera de SSH habilitado, tiempo de espera de consola inactiva, modo automático).

• Expulsar – Cuando un servidor es expulsado de un pool, se restauran las configuraciones predeterminadas.

  • XenServer 8.4: SSH habilitado, modo automático desactivado

Definición del nuevo control de gestión de SSH

Establezca la nueva API XAPI pool.set_ssh_auto_mode a nivel de pool para configurar SSH

set_ssh_auto_mode: Configure para habilitar o deshabilitar el modo automático de SSH. Cuando el modo automático está habilitado, el estado de SSH depende del estado de XAPI: SSH está deshabilitado cuando XAPI está en buen estado, y SSH está habilitado cuando XAPI no está en buen estado.

Cuando un usuario establece el modo automático en habilitado y el ssh_enabled_timeout actual es 0, habilitar SSH con pool.enable_ssh deshabilitará permanentemente el modo automático.

Cuando un usuario establece el modo automático con pool.set_auto_mode como habilitado o deshabilitado, esto se denomina la “configuración original del modo automático”. Si el ssh_enabled_timeout actual se establece en un número positivo (por ejemplo, 1800 segundos), habilitar SSH con pool.enable_ssh deshabilitará temporalmente el modo automático. Cuando expire el período de tiempo de espera, SSH se deshabilitará automáticamente y el modo automático se restaurará a su configuración original.

Cuando un usuario establece ssh_enabled_timeout en un número positivo (por ejemplo, 3600 segundos) y reinicia el host (o reinicia XAPI) antes de que expire el período de tiempo de espera, una vez que expire el período de tiempo de espera, SSH se deshabilitará automáticamente y el modo automático se restaurará a verdadero, ya que el reinicio habrá perdido la configuración original del modo automático.

Cuando configura ssh_enabled_timeout en un número positivo (por ejemplo, 180 segundos) y XAPI falla posteriormente, si XAPI permanece en un estado fallido cuando expira el período de tiempo de espera, SSH permanecerá habilitado hasta que XAPI se reinicie. Tras el reinicio de XAPI, SSH se deshabilitará automáticamente y el modo automático se restaurará a verdadero, ya que el reinicio del sistema provoca la pérdida de la configuración original del modo automático.

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](/en-us/xenserver/9/hosts-pools/manage-hosts#configure-ssh-access).-->

## Configurar sesiones de consola VNC

De forma predeterminada, XenServer no limita el número de sesiones de consola VNC concurrentes por VM o host. Puede restringir el acceso y aplicar tiempos de espera de inactividad a nivel de pool.

Para limitar cada consola de VM o host a una sesión concurrente:

xe pool-param-set uuid= limit-console-sessions=true

Cuando está habilitado, los intentos de conexión adicionales se rechazan con un error que identifica al usuario actualmente conectado. Para comprobar el valor actual:

xe pool-param-get uuid= param-name=limit-console-sessions

Para establecer un tiempo de espera de inactividad para las sesiones de consola de VM (domU):

xe pool-param-set uuid= vm-console-idle-timeout= ```

Establezca en 0 para deshabilitar el tiempo de espera (las sesiones nunca caducan). Un valor positivo desconecta automáticamente las sesiones de consola de VM inactivas después del número de segundos especificado.

Nota:

El parámetro console-idle-timeout controla el tiempo de inactividad de las consolas del dominio de control (Dom0) y las sesiones SSH. El parámetro vm-console-idle-timeout se aplica solo a las consolas de VM.

Habilitar el snooping IGMP en su pool de XenServer

XenServer envía tráfico de multidifusión a todas las máquinas virtuales invitadas, lo que provoca una carga innecesaria en los dispositivos del host al requerirles que procesen paquetes que no han solicitado. La habilitación del snooping IGMP evita que los hosts de una red local reciban tráfico para un grupo de multidifusión al que no se han unido explícitamente, y mejora el rendimiento de la multidifusión. El snooping IGMP es especialmente útil para aplicaciones de multidifusión IP que consumen mucho ancho de banda, como IPTV.

Notas:

• Al habilitar esta función en un pool, también puede ser necesario habilitar el querier IGMP en uno de los conmutadores físicos. De lo contrario, la multidifusión en la subred vuelve a la difusión y puede disminuir el rendimiento de XenServer.

• Al habilitar esta función en un pool que ejecuta IGMP v3, la migración de VM o la conmutación por error de enlace de red resultan en un cambio de versión de IGMP a v2.

• Para habilitar esta función con una red GRE, los usuarios deben configurar un Querier IGMP en la red GRE. Alternativamente, puede reenviar el mensaje de consulta IGMP de la red física a la red GRE. De lo contrario, el tráfico de multidifusión en la red GRE puede ser bloqueado.

Puede habilitar el snooping IGMP en un pool usando XenCenter o la CLI de xe.

XenCenter

1. Vaya a Propiedades del pool.
2. Seleccione Opciones de red. Aquí puede habilitar o deshabilitar el snooping IGMP.

CLI de xe

1. Obtenga el UUID del pool:

   xe pool-list

2. Habilitar/deshabilitar el rastreo IGMP para el pool:

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

Después de habilitar el rastreo IGMP, puede ver la tabla de rastreo IGMP usando la CLI de xe.

Ver la tabla de rastreo IGMP

Utilice el siguiente comando para ver la tabla de rastreo IGMP:

ovs-appctl mdb/show [bridge name]

Nota:

Puede obtener el nombre del puente usando xe network-list. Estos nombres de puente pueden ser xenbr0, xenbr1, xenapi o xapi0.

Esto genera una tabla con cuatro columnas:

• port: El puerto del conmutador (OVS).
• VLAN: El ID de VLAN del tráfico.
• GROUP: El grupo de multidifusión que solicitó el puerto.
• Age: La antigüedad de este registro en segundos.

Si el GRUPO es una dirección de grupo de multidifusión, esto significa que se recibe un mensaje de informe IGMP en el puerto del conmutador asociado. Esto significa que un receptor (miembro) del grupo de multidifusión está escuchando en este puerto.

Considere el siguiente ejemplo que contiene dos registros:

El primer registro muestra que hay un receptor escuchando en el puerto 14 para el grupo de multidifusión 227.0.0.1. El Open vSwitch reenvía el tráfico destinado al grupo de multidifusión 227.0.0.1 solo a los puertos de escucha para este grupo (en este ejemplo, el puerto 14), en lugar de transmitirlo a todos los puertos. El registro que vincula el puerto 14 y el grupo 227.0.0.1 se creó hace 15 segundos. Por defecto, el intervalo de tiempo de espera es de 300 segundos. Esto significa que si el conmutador no recibe más mensajes de informe IGMP en el puerto 14 durante 300 segundos después de añadir el registro, el registro caduca y se elimina de la tabla.

En el segundo registro, el GRUPO es consultor, lo que significa que se han recibido mensajes de consulta IGMP en el puerto asociado. Un consultor envía periódicamente mensajes de consulta IGMP, que se transmiten a todos los puertos del conmutador, para determinar qué nodos de red están escuchando en un grupo de multidifusión. Al recibir un mensaje de consulta IGMP, el receptor responde con un mensaje de informe IGMP, lo que hace que el registro de multidifusión del receptor se actualice y evite la caducidad.

La columna VLAN indica la VLAN en la que reside un receptor/consultor. ‘0’ significa VLAN nativa. Si desea ejecutar multidifusión en alguna VLAN etiquetada, asegúrese de que haya registros en esa VLAN.

Nota:

Para el escenario de VLAN, debe tener un registro de consultor con un valor de columna VLAN igual al ID de VLAN de la red; de lo contrario, la multidifusión no funcionará en la red VLAN.

Habilitar la compresión del flujo de migración en su pool de XenServer

Durante la migración en vivo de una VM, su memoria se transfiere como un flujo de datos entre dos hosts utilizando la red. La función de compresión del flujo de migración comprime este flujo de datos, acelerando la transferencia de memoria en redes lentas. Esta función está deshabilitada de forma predeterminada, pero se puede cambiar usando XenCenter o la CLI de xe. Para obtener más información, consulte Propiedades del pool - Avanzado y Parámetros del pool. Alternativamente, puede habilitar la compresión al migrar una VM usando la línea de comandos. Para obtener más información, consulte el comando vm-migrate en Comandos de VM.

Exportar datos del pool de recursos

La opción Exportar datos de recursos le permite generar un informe de datos de recursos para su pool y exportarlo a un archivo .xls o .csv. Este informe proporciona información detallada sobre varios recursos en el pool, como hosts, redes, almacenamiento, máquinas virtuales, VDI y GPU. Esta función permite a los administradores rastrear, planificar y asignar recursos en función de diversas cargas de trabajo, como CPU, almacenamiento y red.

Nota:

La exportación de datos del pool de recursos está disponible para los clientes de XenServer Premium Edition.

La lista de recursos y varios tipos de datos de recursos que se incluyen en el informe:

Servidor:

• Nombre
• Coordinador del pool
• UUID
• Dirección
• Uso de CPU
• Red (media/máx KBs)
• Memoria utilizada
• Almacenamiento
• Tiempo de actividad
• Descripción

Redes:

• Nombre
• Estado del enlace
• MAC
• MTU
• VLAN
• Tipo
• Ubicación

VDI:

• Nombre
• Tipo
• UUID
• Tamaño
• Almacenamiento
• Descripción

Almacenamiento:

• Nombre
• Tipo
• UUID
• Tamaño
• Ubicación
• Descripción

Máquinas virtuales:

• Nombre
• Estado de energía
• En ejecución en
• Dirección
• MAC
• NIC
• Sistema operativo
• Almacenamiento
• Memoria utilizada
• Uso de CPU
• UUID
• Tiempo de actividad
• Plantilla
• Descripción

GPU:

• Nombre
• Servidores
• Ruta del bus PCI
• UUID
• Uso de energía
• Temperatura
• Memoria utilizada
• Utilización del equipo

Nota:

La información sobre las GPU solo está disponible si hay GPU conectadas a su host XenServer.

Para exportar datos de recursos

1. En el panel de navegación de XenCenter, seleccione Infraestructura y, a continuación, seleccione el grupo.

2. Seleccione el menú Grupo y, a continuación, Exportar datos de recursos.

3. Busque una ubicación donde desee guardar el informe y, a continuación, haga clic en Guardar.