Citrix Hypervisor

Hosts y grupos de recursos

April 11, 2024

Contribución de:

En esta sección se describe cómo se pueden crear grupos de recursos mediante una serie de ejemplos utilizando la interfaz de línea de comandos (CLI) xe. Se presenta una configuración de almacenamiento compartido simple basada en NFS y se analizan varios ejemplos sencillos de administración de VM. También contiene procedimientos para tratar los fallos de los nodos físicos.

Descripción general de los grupos de recursos y servidores de Citrix Hypervisor

Un grupo de recursos comprende varias instalaciones de servidores de Citrix Hypervisor, unidas entre sí a una sola entidad administrada que puede alojar máquinas virtuales. Si se combina con el almacenamiento compartido, un grupo de recursos permite que las VM se inicien en cualquier servidor de Citrix Hypervisor que tenga suficiente memoria. Las VM se pueden mover dinámicamente entre los servidores de Citrix Hypervisor mientras se ejecutan con un tiempo de inactividad mínimo (migración en vivo). Si un servidor de Citrix Hypervisor individual sufre un error de hardware, el administrador puede reiniciar las máquinas virtuales con errores en otro servidor de Citrix Hypervisor en el mismo grupo de recursos. Cuando se habilita la alta disponibilidad en el grupo de recursos, las máquinas virtuales se mueven automáticamente a otro host cuando su host falla. Se admiten hasta 64 hosts por grupo de recursos, aunque esta restricción no se aplica.

Un grupo siempre tiene al menos un nodo físico, conocido como maestro. Solo el nodo maestro expone una interfaz de administración (utilizada por XenCenter y la interfaz de línea de comandos de Citrix Hypervisor, conocida como la CLI de xe). El maestro reenvía los comandos a los miembros individuales según sea necesario.

Nota:

Cuando el maestro del grupo falla, la reelección del maestro se lleva a cabo solo si se habilita la alta disponibilidad.

Requisitos para crear grupos de recursos

Una agrupación de recursos es un agregado homogéneo (o heterogéneo con restricciones) de uno o más servidores de Citrix Hypervisor, hasta un máximo de 64. La definición de homogéneo es:

Las CPU del servidor que se une al grupo son las mismas (en términos del proveedor, el modelo y las funciones) que las CPU de los servidores que ya están en el grupo.
El servidor que se une al grupo ejecuta la misma versión del software de Citrix Hypervisor, con el mismo nivel de parche, que los servidores que ya están en el grupo.

El software impone restricciones adicionales al unir un servidor a un grupo. En particular, Citrix Hypervisor comprueba que se cumplan las siguientes condiciones para el servidor que se une al grupo:

El servidor no es miembro de un grupo de recursos existente.
El servidor no tiene configurado almacenamiento compartido.
El servidor no aloja ninguna VM en ejecución o suspendida.
No hay operaciones activas en curso en las VM del servidor, como el cierre de una VM.
El reloj del servidor se sincroniza al mismo tiempo que el maestro del grupo (por ejemplo, mediante NTP).
La interfaz de administración del servidor no está enlazada. Puede configurar la interfaz de administración cuando el servidor se una correctamente al grupo.
La dirección IP de administración es estática, ya sea configurada en el propio servidor o mediante una configuración apropiada en el servidor DHCP.

Los servidores de Citrix Hypervisor de los grupos de recursos pueden contener diferentes números de interfaces de red físicas y tener repositorios de almacenamiento locales de distintos tamaños. En la práctica, a menudo es difícil obtener varios servidores con exactamente las mismas CPU, por lo que se permiten variaciones menores. Si es aceptable tener hosts con diferentes CPU como parte del mismo grupo, puede forzar la operación de unión de grupos pasando el parámetro --force.

Todos los hosts del grupo deben estar en el mismo sitio y conectados mediante una red de baja latencia.

Nota:

Los servidores que proporcionan almacenamiento NFS o iSCSI compartido para el grupo deben tener una dirección IP estática.

Un grupo debe contener repositorios de almacenamiento compartidos para seleccionar en qué servidor de Citrix Hypervisor ejecutar una VM y mover una VM entre los servidores de Citrix Hypervisor de forma dinámica. Si es posible, cree un grupo después de que haya almacenamiento compartido disponible. Le recomendamos que mueva las VM existentes con discos ubicados en el almacenamiento local al almacenamiento compartido después de agregar almacenamiento compartido. Puede usar el comando xe vm-copy o usar XenCenter para mover las máquinas virtuales.

Crear un grupo de recursos

Los grupos de recursos se pueden crear mediante XenCenter o la CLI. Cuando un nuevo host se une a un grupo de recursos, el host que se une sincroniza su base de datos local con la de todo el grupo y hereda algunos ajustes del grupo:

La configuración de almacenamiento de VM, local y remoto se agrega a la base de datos de todo el grupo. Esta configuración se aplica al host que se une al grupo, a menos que haga que los recursos se compartan explícitamente después de que el host se una al grupo.
El host que se une hereda los repositorios de almacenamiento compartidos existentes en el grupo. Se crean 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: todos los detalles estructurales de las NIC, las VLAN y las interfaces enlazadas se heredan, pero la información de directivas no. Esta información de directiva, 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 sigue siendo la misma que la configuración original. Por ejemplo, si los otros hosts del grupo tienen interfaces de administración en una interfaz enlazada, el host que se une se debe migrar al enlace después de unirse.
- NIC de almacenamiento dedicado, que deben reasignarse al host que se une desde XenCenter o la CLI, y los PBD se deben volver a conectar para redirigir 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 de grupo y la NIC de almacenamiento solo funciona cuando está configurada correctamente. Para obtener más información sobre cómo dedicar una NIC de almacenamiento desde la CLI, consulte Administrar redes.

Nota:

Solo puede unir un nuevo host a un grupo de recursos cuando la interfaz de administración del host está en la misma VLAN etiquetada que la del grupo de recursos.

Agregar un host a una agrupación mediante la CLI xe

Abra una consola en el host de Citrix Hypervisor que quiera unir a un grupo.
Une el host de Citrix Hypervisor al grupo emitiendo el comando:
```
xe pool-join master-address=<address of pool coordinator> master-username=<administrator username> master-password=<password>

```
master-address debe configurarse en el nombre de dominio completo del coordinador de la agrupación. password Debe ser la contraseña de administrador establecida cuando se instaló el coordinador de la agrupación.

Nota:

Al unir un anfitrión 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 servidores de Citrix Hypervisor 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 tab-complete para encontrar pool_uuid:

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

Crear grupos de recursos heterogéneos

Citrix Hypervisor simplifica las implementaciones en expansión 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 mediante el uso de tecnologías en las CPU Intel (FlexMigration) y AMD (migración extendida) que proporcionan “enmascaramiento” o “nivelación” de la 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 a la que realmente ofrece. Esta función le permite crear grupos de hosts con CPU diferentes, pero aun así admitir la migración en vivo de forma segura.

Nota:

Las CPU de los servidores Citrix Hypervisor que se unen a grupos heterogéneos deben ser del mismo proveedor (es decir, AMD o Intel) que las CPU de los hosts que ya están en el grupo. Sin embargo, no es necesario que los servidores sean del mismo tipo a nivel de familia, modelo o número escalonado.

Citrix Hypervisor simplifica el soporte de grupos heterogéneos. Los hosts ahora se pueden agregar a los grupos de recursos existentes, independientemente del tipo de CPU subyacente (siempre que la CPU pertenezca a la misma familia de proveedores). El conjunto de funciones del grupo se calcula dinámicamente cada vez:

Un nuevo anfitrión se une al grupo
Un miembro del grupo abandona el grupo
Un miembro del grupo se vuelve a conectar después de reiniciar

Cualquier cambio en el conjunto de funciones del grupo no afecta a las máquinas virtuales que se ejecutan actualmente en el grupo. Una máquina virtual en ejecución sigue utilizando el conjunto de funciones que se aplicó cuando se inició. Este conjunto de funciones se corrige en el arranque y persiste en las operaciones de migración, suspensión y reanudación. Si el nivel del grupo disminuye cuando un host con menos capacidad se une al grupo, una VM en ejecución se puede migrar a cualquier host del grupo, excepto al host recién agregado. Cuando mueve o migra una máquina virtual a un host diferente dentro o entre grupos, Citrix Hypervisor compara el conjunto de funciones de la VM 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 de los grupos y entre ellos, independientemente de las funciones de CPU que esté utilizando la máquina virtual. Si usa Equilibrio de carga de trabajo para seleccionar un host de destino óptimo para migrar su VM, no se recomendará un host con un conjunto de funciones incompatible como host de destino.

Agregar almacenamiento compartido

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

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

Abra una consola en cualquier servidor de Citrix Hypervisor del grupo.
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

```
device-config:server es el nombre de host del servidor NFS y device-config:serverpath es la ruta del servidor NFS. Como shared se establece en true, el almacenamiento compartido se conecta automáticamente a todos los servidores de Citrix Hypervisor del grupo. Los servidores de Citrix Hypervisor que se unan más tarde también están conectados al almacenamiento. El identificador único universal (UUID) del repositorio de almacenamiento se imprime en la pantalla.
Busque el UUID del grupo ejecutando el siguiente comando:
```
xe pool-list

```
Establezca el almacenamiento compartido como el valor predeterminado de todo el grupo con el siguiente comando:
```
xe pool-param-set uuid=pool_uuid default-SR=sr_uuid

```
Como el almacenamiento compartido se estableció como el valor predeterminado para todo el grupo, todas las máquinas virtuales futuras tendrán sus discos creados en almacenamiento compartido de forma predeterminada. Para obtener información sobre la creación de otros tipos de almacenamiento compartido, consulte Formatos de repositorio de almacenamiento.

Eliminar los servidores de Citrix Hypervisor de un grupo de recursos

Nota:

Antes de eliminar cualquier servidor de Citrix Hypervisor de un grupo, asegúrese de cerrar todas las máquinas virtuales que se ejecutan en ese host. De lo contrario, puede ver una advertencia que indica que el host no se puede eliminar.

Cuando elimina (expulsa) un host de una agrupación, la máquina se reinicia, se reinicializa y se deja en un estado similar al de una instalación nueva. No expulse los servidores de Citrix Hypervisor de un grupo si hay datos importantes en los discos locales.

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

Abra una consola en cualquier host del grupo.
Busque el UUID del host ejecutando el siguiente comando:
```
xe host-list

```
Expulse el host requerido del grupo:
```
xe pool-eject host-uuid=host_uuid

```
El servidor de Citrix Hypervisor se expulsa y se deja en un estado recién instalado.

Advertencia:

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

Cuando los servidores de Citrix Hypervisor que contienen máquinas virtuales almacenadas localmente se expulsan de un grupo, las máquinas virtuales estarán presentes en la base de datos del grupo. Las máquinas virtuales almacenadas localmente también son visibles para los demás servidores de Citrix Hypervisor. Las máquinas virtuales no se inician hasta que los discos vDisk asociados a ellas se hayan cambiado para que apunte al almacenamiento compartido visto por otros servidores de Citrix Hypervisor del grupo, o se hayan quitado. Por lo tanto, le recomendamos que traslade cualquier almacenamiento local a un almacenamiento compartido cuando se una a un grupo. La migración a un almacenamiento compartido permite que los servidores de Citrix Hypervisor individuales se expulsen (o fallen físicamente) sin pérdida de datos.

Nota:

Cuando se elimina un host de un grupo 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.

Preparar un grupo de servidores de Citrix Hypervisor para el mantenimiento

Antes de realizar operaciones de mantenimiento en un host que forma parte de un grupo de recursos, debe inhabilitarlo. La desactivación del host impide que las máquinas virtuales se inicien en él. A continuación, debe migrar sus máquinas virtuales a otro servidor de Citrix Hypervisor del grupo. Para ello, coloque el servidor de Citrix Hypervisor en modo de mantenimiento mediante XenCenter. Para obtener más información, consulte Ejecutar en modo de mantenimiento en la documentación de XenCenter.

La sincronización de reserva se produce cada 24 horas. La colocación del host maestro en modo de mantenimiento provoca la pérdida de las últimas 24 horas de actualizaciones de RRD para las máquinas virtuales sin conexión.

Advertencia:

Recomendamos encarecidamente reiniciar todos los servidores de Citrix Hypervisor antes de instalar una actualización y, a continuación, verificar su configuración. Algunos cambios de configuración solo surten efecto cuando se reinicia el servidor de Citrix Hypervisor, por lo que el reinicio puede revelar problemas de configuración que pueden provocar un error en la actualización.

Para preparar un host en un grupo para las operaciones de mantenimiento mediante la CLI

Ejecute este comando:
```
xe host-disable uuid=Citrix Hypervisor_host_uuid
xe host-evacuate uuid=Citrix Hypervisor_host_uuid

```
Este comando inhabilita el servidor de Citrix Hypervisor y, a continuación, migra cualquier máquina virtual en ejecución a otros servidores de Citrix Hypervisor del grupo.
Realice la operación de mantenimiento deseada.
Habilite el servidor de Citrix Hypervisor cuando finalice la operación de mantenimiento:
```
xe host-enable

```
Reinicie las máquinas virtuales detenidas y reanude las máquinas virtuales suspendidas.

Exportar datos de la agrupación de recursos

La opción Exportar datos de recursos le permite generar un informe de datos de recursos para su grupo y exportar el informe a un archivo XLS o CSV. Este informe proporciona información detallada sobre varios recursos del grupo, como servidores, redes, almacenamiento, máquinas virtuales, VDI y GPU. Esta función permite a los administradores realizar un seguimiento, planificar y asignar recursos en función de diversas cargas de trabajo, como la CPU, el almacenamiento y la red.

Nota:

La exportación de datos del grupo de recursos está disponible para los clientes de Citrix Hypervisor Premium Edition o para aquellos que tienen acceso a Citrix Hypervisor a través de sus derechos de Citrix Virtual Apps and Desktops o de Citrix DaaS.

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

Servidor:

Nombre
Maestro de agrupación
UUID
Dirección
Uso de CPU
Red (kBs promedio/máximo)
Memoria usada
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

VM:

Nombre
Estado de energía
Se ejecuta en
Dirección
MAC
NIC
Sistema operativo
Almacenamiento
Memoria usada
Uso de CPU
UUID
Tiempo de actividad
Plantilla
Descripción

GPU:

Nombre
Servidores
Ruta de bus PCI
UUID
Uso de energía
Temperatura
Memoria usada
Utilización de equipos

Nota:

La información sobre las GPU solo está disponible si hay GPU conectadas a su servidor de Citrix Hypervisor.

Para exportar datos de recursos

En el panel de navegación de XenCenter, seleccione Infraestructura y, a continuación, seleccione la agrupación.
Seleccione el menú Agrupación y luego Exportar datos de recursos.
Vaya a la ubicación en la que quiera guardar el informe y, a continuación, haga clic en Guardar.

Encendido del host

Encender hosts de forma remota

Puede usar la función de encendido del servidor de Citrix Hypervisor para encender y apagar un servidor de forma remota, ya sea desde XenCenter o mediante la CLI.

Para habilitar la alimentación del host, el host debe tener una de las siguientes soluciones de control de energía:

Tarjeta de red habilitada para Wake on LAN.
Tarjetas de acceso remoto de Dell (DRAC). Para usar Citrix Hypervisor con DRAC, debe instalar el paquete complementario de Dell para obtener soporte de DRAC. La compatibilidad con la DRAC requiere la instalación de la utilidad de línea de comandos RACADM en el servidor con el controlador de acceso remoto y la activación de DRAC y su interfaz. RACADM se incluye a menudo en el software de administración de la DRAC. Para obtener más información, consulte la documentación de DRAC de Dell.
Un script personalizado basado en la API de administración que le permite activar y desactivar la alimentación a través de Citrix Hypervisor. Para obtener más información, consulte Configuración de un script personalizado para la función de encendido del host en la siguiente sección.

El uso de la función Host Power On requiere dos tareas:

Asegúrese de que los hosts del grupo admitan el control de la energía de forma remota. Por ejemplo, tienen la funcionalidad Wake on LAN o una tarjeta DRAC, o usted ha creado un script personalizado).
Habilite la funcionalidad de encendido del host mediante la CLI o XenCenter.

Usar la CLI para administrar el encendido del host

Puede administrar la función Host Power On mediante la CLI o XenCenter. En esta sección se proporciona información sobre cómo administrarlo con la CLI.

El encendido del host está habilitado en el nivel de host (es decir, en cada Citrix Hypervisor).

Después de habilitar el encendido del host, puede activar los hosts mediante la CLI o XenCenter.

Para habilitar el encendido del host mediante la CLI

Ejecute el comando:

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

Para DRAC, las claves power_on_ip deben especificar la contraseña si está utilizando la función secreta. Para obtener más información, consulte Secretos.

Para activar hosts de forma remota mediante la CLI

Ejecute el comando:

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

Configurar un script personalizado para la función Host Power On

Si la solución de energía remota de su servidor utiliza un protocolo que no es compatible de forma predeterminada (como Wake-On-Ring o Intel Active Management Technology), puede crear un script de Linux Python personalizado para activar los equipos Citrix Hypervisor de forma remota. Sin embargo, también puede crear scripts personalizados para las soluciones de energía remota DRAC y Wake on LAN.

En esta sección se proporciona información sobre la configuración de un script personalizado para Host Power On mediante los pares clave/valor asociados a la llamada a la API de Citrix Hypervisor host.power_on.

Cuando cree un script personalizado, ejecútelo desde la interfaz de línea de comandos cada vez que quiera controlar la energía de forma remota en un servidor Citrix Hypervisor. Como alternativa, puede especificarlo en XenCenter y usar las funciones de la interfaz de usuario de XenCenter para interactuar con él.

La API de Citrix Hypervisor se documenta en el documento, la API de administración de Citrix Hypervisor, que está disponible en el sitio web de documentación para desarrolladores.

Advertencia:

No cambie los scripts proporcionados de forma predeterminada en el directorio /etc/xapi.d/plugins/. Puede incluir nuevos scripts en este directorio, pero nunca debe cambiar los scripts contenidos en ese directorio después de la instalación.

Pares clave/valor

Para usar Host Power On, configure las teclas host.power_on_mode y host.power_on_config. Consulte la siguiente sección para obtener información sobre los valores.

También hay una llamada a la API que le permite configurar estos campos simultáneamente:

void host.set_host_power_on_mode(string mode, Dictionary<string,string> config)
<!--NeedCopy-->

host.power_on_mode

Definición: contiene pares clave/valor para especificar el tipo de solución de alimentación remota (por ejemplo, DRAC de Dell).
Valores posibles:
- Una cadena vacía, que representa el control de potencia desactivado.
- “DRAC”: Le permite especificar Dell DRAC. Para usar la DRAC, ya debe haber instalado el paquete complementario de Dell.
- “wake-on-lan”: permite especificar Wake on LAN.
- Cualquier otro nombre (utilizado para especificar un script de encendido personalizado). Esta opción se usa para especificar un script personalizado para la administración de energía.
Tipo: cuerda

host.power_on_config

Definición: contiene pares clave/valor para la configuración de modo. Proporciona información adicional para la DRAC.
Valores posibles:
- Si configuró la DRAC como el tipo de solución de energía remota, también debe especificar una de las siguientes claves:
  - “power_on_ip”: La dirección IP que especificó configuró para comunicarse con la tarjeta de control de alimentación. Como alternativa, puede escribir el nombre de dominio de la interfaz de red en la que está configurada la DRAC.
  - “power_on_user”: El nombre de usuario de la DRAC asociado al procesador de administración, que puede haber cambiado de su configuración predeterminada de fábrica.
  - “power_on_password_secret”: Especifica el uso de la función de secretos para proteger su contraseña.
- Para utilizar la función de secretos para almacenar su contraseña, especifique la clave “power_on_password_secret”. Para obtener más información, consulte Secretos.
Tipo: Asignación (cadena, cadena)

Script de ejemplo

El script de ejemplo importa la API de Citrix Hypervisor, se define como un script personalizado y, a continuación, pasa parámetros específicos al host que quiere controlar de forma remota. Debe definir los parámetros session en todos los scripts personalizados.

El resultado aparece cuando el script no es correcto.

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

Nota:

Después de crear el script, guárdelo en /etc/xapi.d/plugins con una extensión .py.

Comunicarse con los servidores y los grupos de recursos de Citrix Hypervisor

TLS

Citrix Hypervisor usa el protocolo TLS 1.2 para cifrar el tráfico de la API de administración. Cualquier comunicación entre Citrix Hypervisor y los clientes (o dispositivos) de la API de administración utiliza el protocolo TLS 1.2.

Importante:

No admitimos modificaciones por parte de los clientes en la funcionalidad criptográfica del producto.

Citrix Hypervisor usa el siguiente conjunto de cifrado:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Además, los siguientes conjuntos de cifrado también se admiten para la compatibilidad con versiones anteriores de algunas versiones 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

Nota:

Estos conjuntos de cifrado adicionales utilizan el modo CBC. Aunque algunas organizaciones prefieren el modo GCM, Windows Server 2012 R2 no admite los conjuntos de cifrado RSA con modo GCM. Los clientes que se ejecutan en Windows Server 2012 R2 y que se conectan a un servidor o grupo de Citrix Hypervisor pueden necesitar usar estos conjuntos de cifrado en modo CBC.

SSH

Cuando se usa un cliente SSH para conectarse directamente al servidor de Citrix Hypervisor, se pueden usar los siguientes algoritmos:

Cifrados:

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

MAC:

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

Nota:

Para restringir los conjuntos de cifrado disponibles solo a los de la lista anterior, asegúrese de instalar el parche rápido XS82E015 para Citrix Hypervisor 8.2.

Si quiere inhabilitar el acceso SSH a su servidor de Citrix Hypervisor, puede hacerlo en xsconsole.

En XenCenter, abra la consola del servidor e inicie sesión como root.
Escriba xsconsole.
En xsconsole, vaya a Configuración de servicio remoto > Habilitar/inhabilitar Shell remoto.

La consola muestra si el shell remoto está habilitado.
Para cambiar si el shell remoto está habilitado o inhabilitado, presione Entrar.

Importante:

No admitimos modificaciones por parte de los clientes en la funcionalidad criptográfica del producto.

Instale un certificado TLS en su servidor

El servidor de Citrix Hypervisor viene instalado con un certificado TLS predeterminado. Sin embargo, para usar HTTPS para proteger la comunicación entre Citrix Hypervisor y Citrix Virtual Apps and Desktops, instale un certificado proporcionado por una entidad de certificación de confianza.

En esta sección se describe cómo instalar certificados mediante la CLI de xe. Para obtener información sobre cómo trabajar con certificados mediante XenCenter, consulte la documentación de XenCenter.

Asegúrese de que su certificado TLS y su clave cumplan con los siguientes requisitos:

El par de certificados y claves son una clave RSA.
La clave coincide con el certificado.
La clave se proporciona en un archivo independiente del certificado.
El certificado se proporciona en un archivo independiente de los certificados intermedios.
El archivo de claves debe ser de uno de los siguientes tipos: .pem o .key.
Los archivos de certificados deben ser de uno de los siguientes tipos: .pem, .cer o .crt.
La clave es mayor o igual a 2048 bits y menor o igual a 4096 bits de longitud.
La clave es una clave PKCS #8 sin cifrar y no tiene una clave de paso.
La clave y el certificado están en formato ‘PEM’ codificado en base 64.
El certificado es válido y no ha caducado.
El algoritmo de firma es SHA-2 (SHA256).

La CLI de xe le avisa cuando el certificado y la clave que elija no cumplen con estos requisitos.

¿Dónde puedo obtener un certificado TLS?

Es posible que ya tenga un certificado de confianza que quiera instalar en el servidor de Citrix Hypervisor.
Como alternativa, puede crear un certificado en su servidor y enviarlo a la entidad de certificación que prefiera para que lo firme. Este método es más seguro, ya que la clave privada puede permanecer en el servidor de Citrix Hypervisor y no copiarse entre sistemas.

La creación de un certificado TLS tiene los siguientes pasos:

1. Generar una solicitud de firma de certificado

En primer lugar, genere una solicitud de firma de certificado y clave privada. En el servidor de Citrix Hypervisor, lleve a cabo los siguientes pasos:

Para crear un archivo de clave privada, ejecute el siguiente comando:
```
openssl genrsa -des3 -out privatekey.pem 2048

```

Elimine la contraseña de la clave:

openssl rsa -in privatekey.pem -out privatekey.nop.pem
<!--NeedCopy-->

Cree la solicitud de firma de certificado mediante la clave privada:
```
openssl req -new -key privatekey.nop.pem -out csr

```
Siga las instrucciones para proporcionar la información necesaria para generar la solicitud de firma de certificado.
- Nombre del país. Introduzca los códigos de país del certificado TLS para su país. Por ejemplo, CA para Canadá o JM para Jamaica. Puede encontrar una lista de códigos de países de certificados TLS en la web.
- Nombre delestado o provincia (nombre completo). Introduzca el estado o la provincia donde se encuentra la agrupación. Por ejemplo, Massachusetts o Alberta.
- Nombre de la localidad. Nombre de la ciudad donde se encuentra la agrupación.
- Nombre de la organización. El nombre de su empresa u organización.
- Nombre de la unidad organizativa. Introduzca el nombre del departamento. Este campo es opcional.
- Nombre común. Introduzca el FQDN de su servidor de Citrix Hypervisor. Citrix recomienda especificar un FQDN o una dirección IP que no caduque.
- Dirección de correo. Esta dirección de correo electrónico se incluye en el certificado cuando lo genera.
La solicitud de firma de certificado se guarda en el directorio actual y se denomina csr.
Para mostrar la solicitud de firma de certificados en la ventana de la consola, ejecute el siguiente comando:
```
cat csr

```

Copie la solicitud de firma de certificado completa y use esta información para solicitar el certificado a la entidad de certificación.

Ejemplo de solicitud de firma de certificado:

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

2. Enviar la solicitud de firma del certificado a una autoridad certificadora

Ahora que ha generado la solicitud de firma del certificado, puede enviarla a la entidad de certificación preferida de su organización.

Una entidad de certificación es un tercero de confianza que proporciona certificados digitales. Algunas autoridades de certificación exigen que los certificados estén alojados en un sistema al que se pueda acceder desde Internet. Recomendamos no utilizar una entidad de certificación con este requisito.

La entidad de certificación responde a su solicitud de firma y proporciona los siguientes archivos:

el certificado firmado
un certificado raíz
si procede, un certificado intermedio

Ahora puede instalar todos estos archivos en su servidor Citrix Hypervisor.

3. Instale el certificado firmado en su servidor Citrix Hypervisor

Después de que la entidad de certificación responda a la solicitud de firma del certificado, complete los siguientes pasos para instalar el certificado en el servidor de Citrix Hypervisor:

Obtenga el certificado firmado, el certificado raíz y, si la entidad de certificación tiene uno, el certificado intermedio de la entidad de certificación.
Copie la clave y los certificados en el servidor de Citrix Hypervisor.

Ejecute el siguiente comando en el servidor:

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

El parámetro certificate-chain es opcional.

Para mayor seguridad, puede eliminar el archivo de clave privada después de instalar el certificado.

Administrar la contraseña de administrador

Cuando instala por primera vez un servidor Citrix Hypervisor, establece una contraseña de administrador o raíz. Utilice esta contraseña para conectar XenCenter al servidor o (con el nombre de usuario root) para iniciar sesión en xsconsole, la consola de configuración del sistema.

Si une un servidor a un grupo, la contraseña de administrador del servidor se cambia automáticamente para que coincida con la contraseña de administrador del maestro del grupo.

Nota:

Las contraseñas de administrador de Citrix Hypervisor solo deben contener caracteres ASCII.

Cambiar la contraseña

Puede usar XenCenter, la CLI de xe o xsconsole para cambiar la contraseña del administrador.

XenCenter

Para cambiar la contraseña de administrador de un grupo o servidor independiente mediante XenCenter, siga estos pasos:

En el panel Recursos, seleccione el grupo o cualquier servidor del grupo.
En el menú Agrupación o en el menú Servidor, seleccione Cambiar contraseña del servidor.

Para cambiar la contraseña raíz de un servidor independiente, seleccione el servidor en el panel Recursos y haga clic en Contraseña y, a continuación, en Cambiar en el menú Servidor.

Si XenCenter está configurado para guardar las credenciales de inicio de sesión del servidor entre sesiones, se recuerda la nueva contraseña. Para obtener más información, consulte Almacenar el estado de conexión del servidor.

Después de cambiar la contraseña de administrador, rote el secreto del grupo. Para obtener más información, consulte Rotar el secreto de la agrupación.

CLI de xe

Para cambiar la contraseña del administrador mediante la CLI de xe, ejecute el siguiente comando en un servidor del grupo:

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

Nota:

Asegúrese de anteponer un espacio al comando para evitar almacenar la contraseña de texto sin formato en el historial de comandos.

Después de cambiar la contraseña de administrador, rote el secreto del grupo. Para obtener más información, consulte Rotar el secreto de la agrupación.

xsconsole

Para cambiar la contraseña de administrador de un grupo o un servidor independiente mediante xsconsole, siga estos pasos:

En el maestro del grupo, vaya a la consola.
Inicie sesión como root.
Escriba xsconsole. Presiona Entrar. Se muestra xsconsole.
En xsconsole, utilice las flechas para ir a la opción Autenticación. Presiona Entrar.
Vaya a Cambiar contraseña. Presione Intro.
Autentíquese con la contraseña de administrador.
En el cuadro de diálogo Cambiar contraseña:
1. Introduzca su contraseña actual.
2. Introduzca una contraseña nueva.
3. Escriba de nuevo la nueva contraseña para confirmarla.
Aparecerá la pantalla Cambio de contraseña correcto. Presione Entrar para cerrarla.

Si el servidor es maestro de grupo, esta contraseña actualizada ahora se propaga a los demás servidores del grupo.

Después de cambiar la contraseña de administrador, rote el secreto del grupo. Para obtener más información, consulte Rotar el secreto de la agrupación.

Restablecer una contraseña root perdida

Si pierde la contraseña de administrador (raíz) del servidor Citrix Hypervisor, puede restablecerla accediendo directamente al servidor.

Reinicie el servidor de Citrix Hypervisor.
Cuando aparezca el menú de GRUB, presione e para modificar la entrada del menú de arranque.
Agregue init=/sysroot/bin/sha la línea que comienza con module2.
Presione Ctrl-X para un arranque en un shell raíz.

En el shell de comandos, ejecute los siguientes comandos:

chroot /sysroot
passwd

(type the new password twice)

sync
/sbin/reboot -f
<!--NeedCopy-->

Si el servidor es maestro de grupo, esta contraseña actualizada ahora se propaga a los demás servidores del grupo.

Después de cambiar la contraseña de administrador, rote el secreto del grupo.

Gira el secreto de la agrupación

El secreto del grupo es un secreto compartido entre los servidores de un grupo que permite al servidor demostrar su pertenencia a un grupo.

Dado que los usuarios con la función de administrador del grupo pueden descubrir este secreto, se recomienda cambiar el secreto del grupo si uno de estos usuarios abandona la organización o pierde su función de administrador de grupo.

Puede rotar el secreto del grupo mediante XenCenter o la CLI de xe.

XenCenter

Para rotar el secreto del grupo de un grupo mediante XenCenter, siga estos pasos:

En el panel Recursos, seleccione el grupo o cualquier servidor del grupo.
En el menú Agrupación, seleccione Rotar secreto de agrupación.

Al rotar el secreto del grupo, también se le pide que cambie la contraseña de root. Si ha rotado el secreto del grupo porque cree que su entorno se ha visto comprometido, asegúrese de cambiar también la contraseña de root. Para obtener más información, consulte Cambiar la contraseña.

CLI de xe

Para rotar el secreto del grupo mediante la CLI de xe, ejecute el siguiente comando en un servidor del grupo:

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

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

Habilite la indagación IGMP en su grupo de Citrix Hypervisor

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

Notas:

La indagación IGMP solo está disponible cuando el back-end de la red usa Open vSwitch.

Al habilitar esta función en un grupo, también puede ser necesario habilitar la consulta IGMP en uno de los conmutadores físicos. O bien la multidifusión en la subred recurre a la difusión y puede disminuir el rendimiento de Citrix Hypervisor.

Al habilitar esta función en un grupo que ejecuta IGMP v3, la migración de VM o la conmutación por error de enlace de red da como resultado que la versión IGMP cambie a v2.

Para habilitar esta función con una red GRE, los usuarios deben configurar un solicitante IGMP en la red GRE. Como alternativa, puede reenviar el mensaje de consulta IGMP desde la red física a la red GRE. O bien, se puede bloquear el tráfico de multidifusión en la red GRE.

Puede habilitar la detección de IGMP en un grupo mediante XenCenter o la CLI xe.

XenCenter

Navegue hasta Propiedades del grupo.
Seleccione Opciones de red. Aquí puede habilitar o inhabilitar la detección de IGMP.

CLI de xe

Obtenga el UUID del grupo:

xe pool-list
Habilitar/inhabilitar la detección de IGMP para la agrupación:

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

Después de habilitar la detección de IGMP, puede ver la tabla de detección de IGMP mediante la CLI xe.

Ver la tabla de espionaje de IGMP

Utilice el siguiente comando para ver la tabla de detección de IGMP:

ovs-appctl mdb/show [bridge name]

Nota:

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

Esto genera una tabla con cuatro columnas:

puerto: El puerto del conmutador (OVS).
VLAN: El ID de VLAN del tráfico.
GRUPO: El grupo de multidifusión que solicitó el puerto.
Edad: la antigüedad de este registro en segundos.

Si el GRUPO es una dirección de grupo de multidifusión, significa que se recibió 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.

Tomemos el ejemplo siguiente, que contiene dos registros:

port	VLAN	GRUPO	Edad
14	0	227.0.0.1	15
1	0	querier	24

El primer registro muestra que hay un receptor que escucha 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 a los puertos de escucha únicamente 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. De forma predeterminada, el intervalo de tiempo de espera es de 300 segundos. Esto significa que si el conmutador no recibe ningún otro mensaje de informe IGMP en el puerto 14 durante 300 segundos después de agregar el registro, el registro caducará y se eliminará de la tabla.

En el segundo registro, el GROUP realizaconsultas, lo que significa que los mensajes de consulta IGMP se han recibido en el puerto asociado. Un consultador 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 de IGMP, el receptor responde con un mensaje de informe de IGMP, que hace que el registro de multidifusión del receptor se actualice y evite su caducidad.

La columna VLAN indica a la VLAN que vive un receptor/consultador. ‘0’ significa VLAN nativa. Si quiere ejecutar la multidifusión en alguna VLAN etiquetada, asegúrese de que haya registros en la VLAN.

Nota:

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

La versión oficial de este contenido está en inglés. Para mayor comodidad, parte del contenido de la documentación de Cloud Software Group solo tiene traducción automática. Cloud Software Group no puede controlar el contenido con traducción automática, que puede contener errores, imprecisiones o un lenguaje inadecuado. No se ofrece ninguna garantía, ni implícita ni explícita, en cuanto a la exactitud, la fiabilidad, la idoneidad o la precisión de las traducciones realizadas del original en inglés a cualquier otro idioma, o que su producto o servicio de Cloud Software Group se ajusten a cualquier contenido con traducción automática, y cualquier garantía provista bajo el contrato de licencia del usuario final o las condiciones de servicio, o cualquier otro contrato con Cloud Software Group, de que el producto o el servicio se ajusten a la documentación no se aplicará en cuanto dicha documentación se ha traducido automáticamente. Cloud Software Group no se hace responsable de los daños o los problemas que puedan surgir del uso del contenido traducido automáticamente.

¿Le ha resultado útil?

Hosts y grupos de recursos

April 11, 2024

Contribución de:

April 11, 2024

Contribución de:

En este artículo

Descripción general de los grupos de recursos y servidores de Citrix Hypervisor
Requisitos para crear grupos de recursos
Crear un grupo de recursos
Agregar un host a una agrupación mediante la CLI xe
Crear grupos de recursos heterogéneos
Agregar almacenamiento compartido
Eliminar los servidores de Citrix Hypervisor de un grupo de recursos
Preparar un grupo de servidores de Citrix Hypervisor para el mantenimiento
Exportar datos de la agrupación de recursos
Encendido del host
Comunicarse con los servidores y los grupos de recursos de Citrix Hypervisor
Instale un certificado TLS en su servidor
Administrar la contraseña de administrador
Gira el secreto de la agrupación
Habilite la indagación IGMP en su grupo de Citrix Hypervisor

¿Le ha resultado útil?