Hosts y grupos de recursos

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

Introducción a los servidores y grupos de recursos de Citrix Hypervisor

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

Un grupo siempre tiene al menos un nodo físico, conocido como maestro. Sólo 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 Xe CLI). El maestro reenvía comandos a miembros individuales según sea necesario.

Nota:

Cuando el maestro de grupo falla, la reelección principal se lleva a cabo sólo si está activada la alta disponibilidad.

Requisitos para crear grupos de recursos

Un fondo de recursos es un agregado homogéneo (o heterogéneo con restricciones) de uno o más servidores 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 características) 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 Citrix Hypervisor, en 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 cumplen las condiciones siguientes para el servidor que se une al grupo:

  • El servidor no es miembro de un grupo de recursos existente.

  • El servidor no tiene ningún almacenamiento compartido configurado.

  • El servidor no aloja ninguna máquina virtual en ejecución o suspendida.

  • No hay operaciones activas en curso en las máquinas virtuales del servidor, como el apagado de una máquina virtual.

  • El reloj del servidor se sincroniza a la misma hora 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 une 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 adecuada en el servidor DHCP.

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

Todos los hosts del grupo deben estar en el mismo sitio y conectados por 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 Citrix Hypervisor ejecutar una máquina virtual y mover una máquina virtual entre servidores Citrix Hypervisor de forma dinámica. Si es posible, cree un grupo después de que el almacenamiento compartido esté disponible. Se recomienda mover las máquinas virtuales existentes con discos ubicados en almacenamiento local al almacenamiento compartido después de agregar almacenamiento compartido. Puede utilizar elxe vm-copy comando o usar XenCenter para mover máquinas virtuales.

Crear un fondo de recursos

Los grupos de recursos se pueden crear mediante XenCenter o la CLI. Cuando un nuevo host se une a un fondo de recursos, el host de unión sincroniza su base de datos local con la de todo el grupo y hereda algunas configuraciones del grupo:

  • La configuración de VM, local y almacenamiento remoto se agrega a la base de datos de toda la agrupación. Esta configuración se aplica al host de unión en el grupo a menos que se compartan explícitamente los recursos después de que el host se une al grupo.

  • El host de unión hereda los repositorios de almacenamiento compartido 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 de unión: los detalles estructurales de las NIC, las VLAN y las interfaces enlazadas se heredan, pero la información de directivas no lo es. 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 de unión debe migrarse al enlace después de unirse.

    • NIC de almacenamiento dedicadas, que deben reasignarse al host de unión desde XenCenter o la CLI, y los PBD se vuelven 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 de grupo y la NIC de almacenamiento sólo funciona cuando está configurada correctamente. ConsulteAdministrar redespara obtener más información sobre cómo dedicar una NIC de almacenamiento de información desde la CLI.

Nota:

Sólo puede unir un host nuevo 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.

Para unir servidores Citrix Hypervisor host1 y host2 en un fondo de recursos mediante la CLI

  1. Abra una consola en el host del servidor Citrix Hypervisor 2.

  2. Ordene a Citrix Hypervisor server host2 que se una al grupo en Citrix Hypervisor server host1 ejecutando el comando:

    xe pool-join master-address=host1 master-username=administrators_username master-password=password
    

    master-address Debe establecerse en el nombre de dominio completo del host del servidor Citrix Hypervisor 1 . password Debe ser la contraseña de administrador establecida cuando se instaló el host del servidor Citrix Hypervisor 1 .

Los servidores Citrix Hypervisor pertenecen a un grupo sin nombre de forma predeterminada. Para crear el primer fondo de recursos, cambie el nombre del grupo sin nombre existente. Utilice tab-complete para buscarpool_uuid:

xe pool-param-set name-label="New Pool" uuid=pool_uuid

Crear grupos de recursos heterogéneos

Citrix Hypervisor simplifica la expansión de las implementaciones a lo largo del tiempo al permitir que el hardware de host dispares se une a un grupo de recursos, conocido como pools de recursos heterogéneos. Los grupos de recursos heterogéneos son posibles mediante el uso de tecnologías en CPU Intel (FlexMigration) y AMD (Extended Migration) que proporcionan «enmascaramiento» o «nivelación» de la CPU. Las características de enmascaramiento y nivelación de CPU permiten configurar una CPU para que aparezca como una marca, modelo o funcionalidad diferente de la que realmente lo hace. Esta función le permite crear grupos de hosts con CPU dispares, pero sigue siendo compatible con la migración en vivo de forma segura.

Nota:

Las CPU de los servidores Citrix Hypervisor que unen grupos heterogéneos deben ser del mismo proveedor (es decir, AMD, Intel) que las CPU de los hosts del grupo. Sin embargo, no es necesario que el tipo específico (familia, modelo y números de paso) sea.

Citrix Hypervisor simplifica la compatibilidad con grupos heterogéneos. Ahora se pueden agregar hosts a los grupos de recursos existentes, independientemente del tipo de CPU subyacente (siempre y cuando la CPU sea de la misma familia de proveedores). El conjunto de entidades de grupo se calcula dinámicamente cada vez:

  • Un nuevo host se une al grupo

  • Un miembro del grupo abandona el grupo

  • Un miembro del grupo se vuelve a conectar tras un reinicio

Cualquier cambio en el conjunto de entidades del grupo no afecta a las máquinas virtuales que se están ejecutando actualmente en el grupo. Una máquina virtual en ejecución continúa utilizando el conjunto de características que se aplicó cuando se inició. Este conjunto de características se fija en el arranque y persiste durante las operaciones de migración, suspensión y reanudación. Si el nivel del grupo disminuye cuando un host menos capaz se une al grupo, se puede migrar una máquina virtual en ejecución 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 características de la máquina virtual con el conjunto de características del host de destino. Si se descubre que los conjuntos de entidades son compatibles, la máquina virtual puede migrar. Esto permite que la máquina virtual se mueva libremente dentro de los grupos y entre ellos, independientemente de las características de CPU que esté utilizando la máquina virtual. Si utiliza Equilibrio de carga de trabajo para seleccionar un host de destino óptimo para migrar la máquina virtual, no se recomendará un host con un conjunto de características incompatibles como host de destino.

Agregar almacenamiento compartido

Para obtener una lista completa de los tipos de almacenamiento compartido admitidos, consulteFormatos de repositorio de almacenamiento. Esta sección 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 fondo de recursos mediante la CLI

  1. Abra una consola en cualquier servidor Citrix Hypervisor del grupo.

  2. Cree el repositorio de almacenamiento en server: /path ejecutando el 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 ydevice-config:serverpath es la ruta de acceso en el servidor NFS. Comoshared se establece en true, el almacenamiento compartido se conecta automáticamente a todos los servidores Citrix Hypervisor del grupo. Los servidores Citrix Hypervisor que se unan posteriormente también están conectados al almacenamiento. El identificador universal único (UUID) del repositorio de almacenamiento se imprime en la pantalla.

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

    xe pool-list
    
  4. Establezca el almacenamiento compartido como el valor predeterminado de toda la agrupación con el comando

    xe pool-param-set uuid=pool_uuid default-SR=sr_uuid
    

    Dado que el almacenamiento compartido se ha establecido como predeterminado para todo el grupo, todas las máquinas virtuales futuras tienen sus discos creados en el almacenamiento compartido de forma predeterminada. ConsulteFormatos de repositorio de almacenamientopara obtener información acerca de la creación de otros tipos de almacenamiento compartido.

Quitar servidores Citrix Hypervisor de un grupo de recursos

Nota:

Antes de quitar cualquier servidor Citrix Hypervisor de un grupo, asegúrese de apagar 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 quitar.

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

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

  1. Abra una consola en cualquier host del grupo.

  2. Busque el UUID del host ejecutando el comando

    xe host-list
    
  3. Expulsar el host requerido del grupo:

    xe pool-eject host-uuid=host_uuid
    

    El servidor 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 desea conservar estos datos, copie la máquina virtual en el almacenamiento compartido del grupo mediante XenCenter o el comandoxe vm-copy CLI.

Cuando los servidores 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 Citrix Hypervisor. Las máquinas virtuales no se inician hasta que los discos virtuales asociados a ellas se hayan cambiado para que apunte al almacenamiento compartido visto por otros servidores Citrix Hypervisor del grupo, o se hayan quitado. Por lo tanto, le recomendamos que mueva cualquier almacenamiento local al almacenamiento compartido al unirse a un grupo. El traslado al almacenamiento compartido permite expulsar (o fallar físicamente) servidores Citrix Hypervisor individuales sin pérdida de datos.

Nota:

Cuando se quita 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 Citrix Hypervisor para el mantenimiento

Antes de realizar operaciones de mantenimiento en un host que forma parte de un grupo de recursos, debe deshabilitarlo. Al deshabilitar el host, se evita que se inicien las máquinas virtuales en él. A continuación, debe migrar sus máquinas virtuales a otro servidor Citrix Hypervisor del grupo. Para ello, coloque el servidor Citrix Hypervisor en el modo Mantenimiento con XenCenter. Consulte la Ayuda de XenCenter para obtener más información.

La sincronización de copia de seguridad se produce cada 24 horas. Al colocar el host maestro en el modo de mantenimiento, se pierden las últimas 24 horas de actualizaciones de RRD para máquinas virtuales sin conexión.

Advertencia:

Recomendamos encarecidamente reiniciar todos los servidores 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 Citrix Hypervisor, por lo que el reinicio puede descubrir problemas de configuración que pueden provocar un error en la actualización.

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

  1. Ejecute el comando siguiente:

    xe host-disable uuid=Citrix Hypervisor_host_uuid
    xe host-evacuate uuid=Citrix Hypervisor_host_uuid
    

    Este comando deshabilita el servidor Citrix Hypervisor y, a continuación, migre cualquier máquina virtual en ejecución a otros servidores Citrix Hypervisor del grupo.

  2. Realice la operación de mantenimiento deseada.

  3. Habilite el servidor Citrix Hypervisor cuando finalice la operación de mantenimiento:

    xe host-enable
    
  4. Reinicie las VM detenidas y reanude las VM suspendidas.

Exportar datos del fondo de recursos

La opción Exportar datos de recursos permite generar un informe de datos de recursos para el grupo y exportar el informe a un archivo.xls o .csv. Este informe proporciona información detallada acerca de 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 CPU, almacenamiento y Red.

Nota:

Export Resource Pool Data está disponible para los clientes de Citrix Hypervisor Premium Edition o aquellos que tienen acceso a Citrix Hypervisor a través de su derecho de Citrix Virtual Apps and Desktops.

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

Servidor:

  • Nombre
  • Maestro de grupo
  • UUID
  • Dirección
  • Uso de CPU
  • Red (promedio de KBs)
  • Memoria usada
  • Almacenamiento
  • Tiempo de actividad
  • Descripción

Redes:

  • Nombre
  • Estado del vínculo
    • MAC
  • MTU
  • VLAN
  • Tipo
  • Ubicación

- ¿DE QUE SE HABLA?

  • 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
  • Ejecutando en
  • Dirección
    • MAC
  • NIC
  • Sistema operativo
  • Almacenamiento
  • Memoria usada
  • Uso de CPU
  • UUID
  • Tiempo de actividad
  • Plantilla
  • Descripción

GPU:

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

Nota:

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

Para exportar datos de recursos

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

  2. Select el menú Pool y, a continuación, Exportar datos de recursos .

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

Encendido del host

Encendido de hosts de forma remota

Puede utilizar la función Encendido del servidor 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 activada por LAN.

  • Tarjetas de acceso remoto de Dell (DRAC). Para utilizar Citrix Hypervisor con DRAC, debe instalar el paquete complementario de Dell para obtener soporte DRAC. La compatibilidad con DRAC requiere instalar la utilidad de línea de comandos RACADM en el servidor con el controlador de acceso remoto y habilitar DRAC y su interfaz. RACADM a menudo se incluye en el software de gestión DRAC. Para obtener más información, consulte la documentación DRAC de Dell.

  • Hewlett-Packard Integrated Lights-Out (iLO). Para utilizar Citrix Hypervisor con iLO, debe habilitar iLO en el host y conectar la interfaz a la red. Para obtener más información, consulte la documentación de iLO de HP.

  • Una secuencia de comandos personalizada basada 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 característica de encendido del host en la sección siguiente.

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

  1. Asegúrese de que los hosts del grupo admiten el control remoto de la alimentación. Por ejemplo, tienen funcionalidad Wake on LAN, una tarjeta DRAC o iLO, o ha creado un script personalizado).

  2. Habilite la funcionalidad Host Power On 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 del host (es decir, en cada Citrix Hypervisor).

Después de habilitar Host Power On, puede activar 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",  "iLO", "DRAC","custom") \
    power-on-config=key:value

Para iLO y DRAC las claves sonpower_on_ip 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>

Configurar un script personalizado para la función de encendido del host

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 una secuencia de comandos de Linux Python personalizada para activar los equipos Citrix Hypervisor de forma remota. Sin embargo, también puede crear scripts personalizados para soluciones de energía remota iLO, DRAC y Wake on LAN.

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

Cuando cree un script personalizado, ejecútelo desde la línea de comandos cada vez que desee controlar la alimentación de forma remota en Citrix Hypervisor. También puede especificarlo en XenCenter y utilizar las funciones de interfaz de usuario de XenCenter para interactuar con él.

La API de Citrix Hypervisor está documentada en el documento, la API de administración de hipervisores de Citrix, que está disponible en eldocumentación del desarrolladorsitio web.

Advertencia:

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

Pares clave/valor

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

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

void host.set_host_power_on_mode(string mode, Dictionary<string,string> config)
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 energía desactivado

    • «iLO»: permite especificar HP iLO.

    • «DRAC»: le permite especificar Dell DRAC. Para utilizar DRAC, debe haber instalado ya 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 utiliza para especificar un script personalizado para la administración de energía.

  • Tipo: cadena

host.power_on_config
  • Definición: Contiene pares clave/valor para la configuración de modo. Proporciona información adicional para iLO y DRAC.

  • Valores posibles:

    • Si configuró iLO o DRAC como el tipo de solución de alimentación remota, también debe especificar una de las claves siguientes:

      • «power_on_ip»: La dirección IP que especificó configuró para comunicarse con la tarjeta de control de alimentación. También puede escribir el nombre de dominio para la interfaz de red donde se configura iLO o DRAC.

      • «power_on_user»: nombre de usuario iLO o DRAC asociado con el 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 tu 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: Mapa (cadena, cadena)

Secuencia de comandos de ejemplo

La secuencia de comandos de ejemplo importa la API de Citrix Hypervisor, se define como una secuencia de comandos personalizada y, a continuación, pasa parámetros específicos al host que desea controlar de forma remota. Debe definir los parámetrossession en todos los scripts personalizados.

El resultado aparece cuando la secuencia de comandos no es correcta.

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

Nota:

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

Comunicarse con servidores y grupos de recursos de Citrix Hypervisor

Citrix Hypervisor utiliza protocolos TLS para cifrar el tráfico de la API de administración. Cualquier comunicación entre Citrix Hypervisor y los clientes de API de administración (o dispositivos) ahora utiliza el protocolo TLS 1.2 de forma predeterminada. Sin embargo, si el cliente de la API de administración o el dispositivo no se comunican mediante TLS 1.2, se pueden utilizar protocolos anteriores para la comunicación.

Citrix Hypervisor utiliza los siguientes conjuntos de cifrado:

-TLS_RSA_WITH_AES_128_CBC_SHA256

-TLS_RSA_WITH_AES_256_CBC_SHA

-TLS_RSA_WITH_AES_128_CBC_SHA

-TLS_RSA_WITH_RC4_128_SHA

-TLS_RSA_WITH_RC4_128_MD5

-TLS_RSA_WITH_3DES_EDE_CBC_SHA

Citrix Hypervisor también le permite configurar su host o grupo de recursos para permitir la comunicación a través de TLS 1.2 solamente. Esta opción permite la comunicación entre Citrix Hypervisor y los clientes de API de administración (o dispositivos) mediante el protocolo TLS 1.2. La opción sólo TLS 1.2 utiliza el conjunto de cifradoTLS_RSA_WITH_AES_128_CBC_SHA256.

Advertencia:

Select la opción sólo TLS 1.2después de asegurarse de que todos los clientes y dispositivos de API de administración que se comunican con el grupo de Citrix Hypervisor son compatibles con TLS 1.2.

Habilitar la indagación IGMP en el grupo de Citrix Hypervisor

Citrix Hypervisor envía tráfico de multidifusión a todas las máquinas virtuales invitadas, lo que lleva a una carga innecesaria en los dispositivos host al exigirles que procesen paquetes que no han solicitado. Habilitar la indagación IGMP impide 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 de ancho de banda, como IPTV.

Puede habilitar la indagación IGMP en un grupo mediante XenCenter o la interfaz de línea de comandos. Para habilitar la indagación IGMP con XenCenter, desplácese hasta Propiedades del grupo y seleccione Opciones de red . Para obtener más información, consulte la Ayuda de XenCenter. Para los comandos xe, consultepiscina-igmp-snooping.

Notas:

  • La indagación IGMP sólo está disponible cuando el back-end de red utiliza Open vSwitch.

  • Al habilitar esta característica 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 se volverá a transmitir y puede disminuir el rendimiento de Citrix Hypervisor.

  • Al habilitar esta característica 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 la red GRE, los usuarios deben configurar un solicitante IGMP en la red GRE. También puede reenviar el mensaje de consulta IGMP desde la red física a la red GRE. O bien, el tráfico de multidifusión en la red GRE se puede bloquear.