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 mediante 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 sencillos de administración de máquinas virtuales. También contiene procedimientos para tratar los errores de los nodos físicos.

Descripción general de los hosts y grupos de recursos de XenServer

Un Grupo de recursos comprende varias instalaciones de host de XenServer, vinculadas 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 iniciar las máquinas virtuales cualquier Host XenServer que tiene suficiente memoria. A continuación, las máquinas virtuales se pueden mover dinámicamente entre hosts de XenServer mientras se ejecutan con un tiempo de inactividad mínimo (migración en vivo). Si un host de XenServer individual sufre un error de hardware, el administrador puede reiniciar las máquinas virtuales con errores en otro host de XenServer en el mismo grupo de recursos. Cuando la alta disponibilidad está habilitada en el grupo de recursos, las máquinas virtuales se mueven automáticamente a otro host cuando se produce un error en su host. 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 Coordinador de Piscina (antes “Pool Master”). El nodo coordinador expone una interfaz de administración (utilizada por XenCenter y la interfaz de línea de comandos de XenServer, conocida como CLI xe). El coordinador envía comandos a los miembros individuales según sea necesario.

Nota: No

Cuando se produce un error en el coordinador del grupo, la reelección del coordinador solo tiene lugar si la alta disponibilidad está habilitada.

Requisitos para crear grupos de recursos

Un grupo de recursos es un agregado homogéneo (o heterogéneo con restricciones) de uno o más hosts XenServer, hasta un máximo de 64. La definición de homogéneo es:

• Las CPU del host que se une al grupo son las mismas (en términos de proveedor, modelo y características) que las CPU de los hosts que ya están en el grupo.

• El host que se une al grupo ejecuta la misma versión del software XenServer, con el mismo nivel de parche, que los hosts que ya están en el grupo.

El software aplica restricciones adicionales al unir un host a un grupo. En particular, XenServer comprueba que se cumplen las siguientes condiciones para el host que se une al grupo:

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

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

• El host no hospeda ninguna máquina virtual en ejecución o suspendida.

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

• El reloj del host se sincroniza a la misma hora que el coordinador del grupo (por ejemplo, mediante NTP).

• La interfaz de administración del host no está vinculada. Puede configurar la interfaz de administración cuando el host se une correctamente al grupo.

• La dirección IP de administración es estática, ya sea configurada en el propio host o mediante una configuración adecuada en el servidor DHCP.

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

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

Nota: No

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 compartido para seleccionar en qué host de XenServer ejecutar una máquina virtual y para mover una máquina virtual entre hosts de XenServer 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 el almacenamiento local al almacenamiento compartido después de agregar el almacenamiento compartido. Puede utilizar la función xe vm-copy o use XenCenter para mover máquinas virtuales.

Creación de 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 de unión sincroniza su base de datos local con la de todo el grupo y hereda algunas opciones de configuración del grupo:

• La configuración de almacenamiento de máquina virtual, local y remoto se agrega a la base de datos de todo el grupo. Esta configuración se aplica al host que se une en el grupo, a menos que los recursos se compartan explícitamente después de que el host se una al grupo.

• El host de unión hereda los repositorios de almacenamiento compartido existentes en el grupo. Se crean los registros PBD adecuados 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: el estructural los detalles de las NIC, VLAN e interfaces enlazadas se heredan, pero política La información no lo es. Esta información de directiva, que se debe reconfigurar, 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 de grupo tienen interfaces de administración en una interfaz vinculada, el host de unión debe migrarse al enlace después de unirse.

  • NIC de almacenamiento dedicado, que se deben reasignar al host de unión desde XenCenter o la CLI, y los PBD reconectados 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 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: No

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.

Adición de un host a un grupo mediante la CLI xe

Nota: No

Se recomienda actualizar el grupo y el host de unión al mismo nivel antes de intentar la unión.

1. Abra una consola en el host de XenServer que desee unir a un grupo.

2. Conecte el host de XenServer al grupo emitiendo el comando:

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

   El dirección-maestra debe establecerse en el nombre de dominio completo del coordinador del grupo. El contraseña Debe ser la contraseña de administrador establecida cuando se instaló el coordinador del grupo.

Nota: No

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.

De forma predeterminada, los hosts de XenServer pertenecen a un grupo sin nombre. Para crear el primer grupo de recursos, cambie el nombre del grupo sin nombre existente. Utilice la tecla tabulación completa para encontrar el archivo pool_uuid:

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

Creación de grupos de recursos heterogéneos

XenServer simplifica la expansión de las implementaciones a lo largo del tiempo al permitir que el hardware de host dispar se una a un grupo de recursos, conocido 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 la CPU. Las funciones de enmascaramiento y nivelación de la CPU permiten configurar una CPU para parecer como proporcionando una marca, modelo o funcionalidad diferente a la que realmente hace. Esta función le permite crear grupos de hosts con CPU dispares, pero aún así admitir de forma segura la migración en vivo.

Nota: No

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

XenServer simplifica la compatibilidad con 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 sea de la misma familia de proveedores). El conjunto de características del 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 después de un reinicio

Cualquier cambio en el conjunto de características 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 sigue usando el conjunto de características que se aplicó cuando se inició. Este conjunto de características se fija 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 máquina virtual en ejecución se puede migrar a cualquier host del grupo, excepto al host recién agregado. Al mover o migrar una máquina virtual a un host diferente dentro de los grupos o entre ellos, 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 características 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 características de CPU que use la máquina virtual. Si utiliza el 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 compatibles, 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

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

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

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

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

4. 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
   <!--NeedCopy-->
   

   Dado que el almacenamiento compartido se ha establecido como el valor predeterminado para todo el grupo, todas las máquinas virtuales futuras tienen sus discos creados en el almacenamiento compartido de forma predeterminada. Para obtener información sobre cómo crear otros tipos de almacenamiento compartido, consulte Formatos de repositorio de almacenamiento.

Eliminar hosts de XenServer de un grupo de recursos

Nota: No

Antes de eliminar cualquier host de XenServer 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 eliminar.

Al eliminar (expulsar) un host de un grupo, el equipo se reinicia, se reinicializa y se deja en un estado similar al de una instalación nueva. No expulse los hosts de XenServer 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. Encuentre el UUID del host ejecutando el siguiente comando:

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

3. Expulse el host requerido del grupo:

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

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

   Advertencia:

   Hacer 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 xe vm-copy Comando CLI.

Cuando los hosts de XenServer 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 hosts de XenServer. Las máquinas virtuales no se inician hasta que los discos virtuales asociados a ellas se han cambiado para que apunten al almacenamiento compartido visto por otros hosts de XenServer en el grupo, o se han eliminado. Por lo tanto, se recomienda mover cualquier almacenamiento local a un almacenamiento compartido al unirse a un grupo. El paso al almacenamiento compartido permite que los hosts individuales de XenServer se expulsen (o fallen físicamente) sin pérdida de datos.

Nota: No

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 hosts de XenServer 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 impide que se inicien las máquinas virtuales en él. A continuación, debe migrar sus máquinas virtuales a otro host de XenServer del grupo. Para ello, coloque el host de XenServer 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 copias de seguridad se produce cada 24 horas. Colocar el coordinador del grupo en modo de mantenimiento da como resultado la pérdida de las últimas 24 horas de actualizaciones de RRD para las máquinas virtuales sin conexión.

Advertencia:

Se recomienda encarecidamente reiniciar todos los hosts de XenServer 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 host de XenServer, por lo que el reinicio puede revelar problemas de configuración que pueden hacer que la actualización falle.

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

1. Ejecute este comando:

     xe host-disable uuid=XenServer_host_uuid
     xe host-evacuate uuid=XenServer_host_uuid
   <!--NeedCopy-->
   

   Este comando inhabilita el host de XenServer y, a continuación, migra las máquinas virtuales en ejecución a otros hosts de XenServer del grupo.

2. Realice la operación de mantenimiento deseada.

3. Habilite el host de XenServer cuando se complete la operación de mantenimiento:

     xe host-enable
   <!--NeedCopy-->
   

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

Exportación de datos del grupo 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 de .xls o .csv. Este informe proporciona información detallada sobre los distintos recursos del grupo, como hosts, 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: No

La opción Exportar datos del grupo 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 de Piscina
• UUID
• Dirección
• Uso de CPU
• Red (promedio/máx. KB)
• Memoria utilizada
• Almacenamiento
• Uptime
• 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

Vms:

• Nombre
• Estado de energía
• Corriendo en
• Dirección
• MAC
• NIC
• Sistema operativo
• Almacenamiento
• Memoria utilizada
• Uso de CPU
• UUID
• Uptime
• Plantilla
• Descripción

GPU:

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

Nota: No

La información sobre las GPU solo está disponible si hay GPU conectadas al host de 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 la opción Piscina menú y luego Exportar datos de recursos.

3. Vaya a la ubicación en la que desee guardar el informe y, a continuación, haga clic en Salvar.

Encendido del host

Encendido de hosts de forma remota

Puede utilizar la función de encendido del host de XenServer para activar y desactivar un host 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.

• Interfaz de gestión de plataforma inteligente (IPMI).

• Un script personalizado basado en la API de administración que permite encender y apagar la alimentación a través de XenServer. 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 de encendido del host requiere dos tareas:

1. Asegúrese de que los hosts del grupo admitan el control de la alimentación de forma remota. Por ejemplo, tienen la funcionalidad Wake on LAN o admiten IPMI, o ha creado un script personalizado.

2. Habilite la funcionalidad de encendido del host mediante la CLI o XenCenter.

Uso de la CLI para administrar el encendido del host

Puede administrar la función de encendido del host 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 XenServer).

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", "IPMI","custom") \
      power-on-config=key:value
<!--NeedCopy-->

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 de encendido del host

Si la solución de alimentación remota del host utiliza un protocolo que no es compatible de forma predeterminada (como Wake-On-Ring o Intel Active Management Technology), puede crear un script personalizado de Linux Python 3 para encender los equipos XenServer de forma remota. Sin embargo, también puede crear scripts personalizados para las soluciones de alimentación remota IPMI y Wake on LAN.

En esta sección se proporciona información sobre cómo configurar un script personalizado para el encendido del host mediante los pares clave-valor asociados a la llamada a la API de XenServer host.power_on.

Al crear un script personalizado, ejecútelo desde la línea de comandos cada vez que desee controlar la energía de forma remota en un host de XenServer. Como alternativa, puede especificarlo en XenCenter y utilizar las funciones de la interfaz de usuario de XenCenter para interactuar con él.

La API de XenServer se documenta en la carpeta API de administración de XenServer.

Advertencia:

No cambie los scripts proporcionados de forma predeterminada en el archivo /etc/xapi.d/plugins/ directorio. 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 utilizar el encendido del host, configure el host.power_on_mode y host.power_on_config Llaves. 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)
<!--NeedCopy-->

host.power_on_mode

• Definición: Contiene pares clave-valor para especificar el tipo de solución de alimentación remota.

• Valores posibles:

  • Una cadena vacía, que representa el control de energía deshabilitado.

  • “IPMI”: Le permite especificar la interfaz de administración de plataforma inteligente.

  • “wake-on-lan”: Le 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:cuerda

host.power_on_config

• Definición: Contiene pares clave/valor para la configuración del modo. Proporciona información adicional para IPMI.

• Valores posibles:

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

    • “power_on_ip”: La dirección IP que especificó configurada para comunicarse con la tarjeta de control de energía.

    • “power_on_user”: el nombre de usuario de IPMI asociado con el procesador de administración, que es posible que haya cambiado de su configuración predeterminada de fábrica.

    • “power_on_password_secret”: especifica el uso de la función de secretos para proteger la 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)

Script de ejemplo

El script de ejemplo importa la API de XenServer, se define a sí mismo como un script personalizado y, a continuación, pasa parámetros específicos del host que desea controlar de forma remota. Debe definir los parámetros sesión en todos los scripts personalizados.

El resultado aparece cuando el script no se realiza correctamente.

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

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

Comunicarse con hosts y grupos de recursos de XenServer

TLS

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

Importante:

No admitimos modificaciones por parte del cliente en la funcionalidad criptográfica del producto.

XenServer utiliza el siguiente conjunto de cifrados:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES128-GCM-SHA256

SSH

Cuando se utiliza un cliente SSH para conectarse directamente al host de XenServer, se pueden utilizar los siguientes algoritmos:

Cifras:

• AES128-CTR
• AES256-CTR
• aes128-gcm@openssh.com
• aes256-gcm@openssh.com

Macs:

• HMAC-SHA2-256
• HMAC-SHA2-512
• HMAC-SHA1

KexAlgoritmos:

• curva25519-sha256
• ECDH-SHA2-NISTAP256
• ECDH-SHA2-NETCP384
• ECDH-SHA2-NISTAP521
• diffie-hellman-grupo14-sha1

Algoritmos de HostKey:

• ECDSA-SHA2-NISTAP256
• ECDSA-SHA2-NISTAP384
• ECDSA-SHA2-NISTAP521
• SSH-ED25519
• SSH-RSA

Si desea inhabilitar el acceso SSH al host de XenServer, puede hacerlo en xsconsola.

1. En XenCenter, abra la consola del host e inicie sesión como raíz.
2. Tipo xsconsola.

3. En xsconsolaVete a Configuración de servicio remoto > Habilitar/deshabilitar Remote Shell.

   La consola muestra si el shell remoto está habilitado.

4. Para cambiar si el shell remoto está habilitado o deshabilitado, presione Entrar.

Importante:

No admitimos modificaciones por parte del cliente en la funcionalidad criptográfica del producto.

Instale un certificado TLS en su host

El host de XenServer viene instalado con un certificado TLS predeterminado. Sin embargo, para usar HTTPS para proteger la comunicación entre XenServer y Citrix Virtual Apps and Desktops, instale un certificado proporcionado por una autoridad 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 el certificado TLS y su clave cumplan los siguientes requisitos:

• El certificado y el par de 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 separado de los certificados intermedios.
• El archivo de claves debe ser de uno de los siguientes tipos: .Pem o .llave.
• Los archivos de certificado deben ser de uno de los siguientes tipos: .Pem, .cero .tubo de rayos catódicos.
• La clave es mayor o igual que 2048 bits y menor o igual que 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 estos requisitos.

¿Dónde puedo obtener un certificado TLS?

• Es posible que ya tenga un certificado de confianza que desee instalar en el host de XenServer.

• Alternativamente, puede crear un certificado en su servidor y enviarlo a su autoridad de certificación preferida para que lo firme. Este método es más seguro, ya que la clave privada puede permanecer en el host de XenServer y no copiarse entre sistemas.

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

  1. Generar una solicitud de firma de certificado
  2. Enviar la solicitud de firma de certificado a una autoridad de certificación
  3. Instale el certificado firmado en el host de XenServer

1. Generar una solicitud de firma de certificado

En primer lugar, genere una clave privada y una solicitud de firma de certificado. En el host de XenServer, siga estos pasos:

1. Para crear un archivo de clave privada, ejecute el siguiente comando:

     openssl genrsa -des3 -out privatekey.pem 2048
   <!--NeedCopy-->
   

   Se le pedirá una frase de contraseña. Esta frase de contraseña se elimina en un paso siguiente.

2. Elimine la frase de contraseña de la clave:

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

3. Cree la solicitud de firma de certificado mediante la clave privada:

     openssl req -new -key privatekey.nop.pem -out csr
   <!--NeedCopy-->
   

4. Siga las indicaciones 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 de su país. Por ejemplo, CA para Canadá o JM para Jamaica. Puede encontrar una lista de códigos de país del certificado TLS en la web.
   • Nombre del estado o provincia (nombre completo). Introduzca el estado o la provincia donde se encuentra el grupo. Por ejemplo, Massachusetts o Alberta.
   • Nombre de la localidad. El nombre de la ciudad donde se encuentra la piscina.
   • 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 del host de XenServer. Se recomienda especificar un FQDN o una dirección IP que no caduque.
   • Dirección de correo electrónico. 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 Rse.

5. Muestre la solicitud de firma de certificado en la ventana de la consola ejecutando el siguiente comando:

     cat csr
   <!--NeedCopy-->
   

6. Copie toda la solicitud de firma de certificado y utilice esta información para solicitar el certificado a la autoridad 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 de certificado a una autoridad de certificación

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

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

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

• El certificado firmado
• en su caso, un certificado intermedio

Ahora puede instalar todos estos archivos en el host de XenServer.

3. Instale el certificado firmado en el host de XenServer

Una vez que la entidad de certificación responda a la solicitud de firma de certificado, complete los siguientes pasos para instalar el certificado en el host de XenServer:

1. Obtenga el certificado firmado y, si la autoridad de certificación tiene uno, el certificado intermedio de la autoridad de certificación.
2. Copie la clave y los certificados en el host de XenServer.

3. Ejecute el siguiente comando en el host:

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

   El cadena-de-certificados 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 se instala por primera vez un host de XenServer, se establece un administrador o raíz contraseña. Utilice esta contraseña para conectar XenCenter a su host o (con nombre de usuario raíz) para iniciar sesión en xsconsola, la consola de configuración del sistema.

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

Nota: No

Las contraseñas de administrador de XenServer solo deben contener caracteres ASCII imprimibles.

Cambiar la contraseña

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

XenCenter

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

1. En Recursos , seleccione el grupo o cualquier host del grupo.
2. En el Piscina menú o en el menú Servidor menú, seleccione Cambiar la contraseña del servidor.

Para cambiar la contraseña de root de un host independiente, seleccione el host en el archivo Recursos y haga clic en Contraseña Y entonces Cambio del Servidor menú.

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

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

xe CLI

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

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

Nota: No

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

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

xsconsola

Para cambiar la contraseña de administrador de un grupo o un host independiente mediante xsconsola, complete los siguientes pasos:

1. En el coordinador de grupo, vaya a la consola.
2. Inicie sesión como raíz.
3. Tipo xsconsola. Prensa Entrar. El xsconsola se muestra.
4. En xsconsola, utilice las teclas de flecha para desplazarse hasta el Autenticación opción. Prensa Entrar.
5. Vaya a Cambiar contraseña. Prensa Entrar.
6. Autentíquese con la contraseña de administrador.
7. En Cambiar contraseña diálogo:
   1. Ingresa tu contraseña actual.
   2. Introduzca una nueva contraseña.
   3. Vuelva a introducir la nueva contraseña para confirmarla.

   El Cambio de contraseña exitoso se muestra la pantalla. Prensa Entrar para desestimar.

Si el host es el coordinador del grupo, esta contraseña actualizada ahora se propaga a los demás hosts del grupo.

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

Restablecer una contraseña de root perdida

Si pierde la contraseña de administrador (raíz) del host de XenServer, puede restablecer la contraseña accediendo directamente al host.

1. Reinicie el host de XenServer.

2. Cuando aparezca el menú de GRUB, presione e para editar la entrada del menú de arranque.

3. Agregar init=/sysroot/bin/sh a la línea que comienza con Módulo2.

4. Prensa Ctrl-X para arrancar en un shell raíz.

5. En el shell de comandos, ejecute los siguientes comandos:

     chroot /sysroot
     passwd
   
     (type the new password twice)
   
     sync
     /sbin/reboot -f
   <!--NeedCopy-->
   

Si el host es el coordinador del grupo, esta contraseña actualizada ahora se propaga a los demás hosts del grupo.

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

Rotar el secreto del grupo

El secreto de grupo es un secreto compartido entre los hosts de un grupo que permite al host demostrar su pertenencia a un grupo.

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

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

XenCenter

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

1. En Recursos , seleccione el grupo o cualquier host del grupo.
2. En el Piscina menú, seleccione Rotar secreto de grupo.

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

xe CLI

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

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

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

Habilitación de la indagación IGMP en el grupo de XenServer

XenServer envía tráfico de multidifusión a todas las máquinas virtuales invitadas, lo que genera 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 han unido explícitamente y mejora el rendimiento de la multidifusión. La indagación IGMP es especialmente útil para aplicaciones de multidifusión IP que hacen un uso intensivo del ancho de banda, como IPTV.

Notes:

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

• Al habilitar esta función en un grupo, también puede ser necesario habilitar el consultante IGMP en uno de los switches 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 grupo que ejecuta IGMP v3, la migración de VM o la conmutación por error de enlace de red dan como resultado el cambio de versión de IGMP a v2.

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

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

XenCenter

1. Vaya a Propiedades de la piscina.
2. Escoger Opciones de red. Aquí puede habilitar o deshabilitar la indagación IGMP.

xe CLI

1. Obtener el UUID del grupo:

   xe pool-list

2. Habilite/deshabilite la indagación IGMP para el grupo:

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

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

Ver la tabla de indagación IGMP

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

ovs-appctl mdb/show [bridge name]

Nota: No

Puede obtener el nombre del puente usando xe lista-de-red. Estos nombres de puente pueden ser: xenbr0, xenbr1, Xenapio xapi0.

Esto genera una tabla con cuatro columnas:

• puerto: El puerto del switch (OVS).
• VLAN: El ID de VLAN del tráfico.
• GROUP: El grupo de multidifusión solicitado por el puerto.
• Edad: La antigüedad de este registro en segundos.

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

Tomemos 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. Open vSwitch reenvía el tráfico destinado al grupo de multidifusión 227.0.0.1 a los puertos de escucha solo para este grupo (en este ejemplo, el puerto 14), en lugar de transmitir 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 switch no recibe más mensajes de informe IGMP en el puerto 14 durante 300 segundos después de agregar el registro, el registro caduca y se elimina de la tabla.

En el segundo registro, el GRUPO es Consultante, lo que significa que se han recibido mensajes de consulta IGMP en el puerto asociado. Un consultante envía periódicamente mensajes de consulta IGMP, que se transmiten a todos los puertos del switch, 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.

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

Nota: No

Para el escenario 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.

Habilitación de la compresión de flujos de migración en el grupo de XenServer

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