layout: doc description: Create resource pools to group your XenServer hosts and shared storage into a single managed entity.—
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.
Un grupo de recursos comprende varias instalaciones host de XenServer, unidas 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 en cualquier host de XenServer que tenga suficiente memoria. Luego, las máquinas virtuales se pueden mover dinámicamente entre los 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 del 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 coordinador del grupo (anteriormente “maestro del grupo”). 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 las órdenes a los miembros individuales según sea necesario.
Nota:
Cuando el coordinador del grupo fracasa, la reelección del coordinador se lleva a cabo solo si se habilita la alta disponibilidad.
Una agrupación 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 funciones) 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 impone restricciones adicionales al unir un anfitrión a un grupo. En concreto, XenServer comprueba que se cumplan las siguientes condiciones para el host que se une al grupo:
El anfitrión no es miembro de un grupo de recursos existente.
El host no tiene ningún almacenamiento compartido configurado.
El host no aloja ninguna máquina virtual suspendida o en ejecución.
No hay operaciones activas en curso en las máquinas virtuales del host, como el cierre 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 una 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 de los grupos de recursos pueden contener diferentes números de interfaces de red físicas y tener repositorios de almacenamiento local de distintos 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 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é host XenServer ejecutar una máquina virtual y para mover una máquina virtual entre los hosts de XenServer 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.
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.
Nota:
Le recomendamos actualizar su grupo y el host que se une al mismo nivel antes de intentar unirse.
Abra una consola en el host de XenServer que quiera unir a un grupo.
Para unir el host de XenServer al grupo, ejecute el comando:
xe pool-join master-address=<address of pool coordinator> master-username=<administrator username> master-password=<password>
<!--NeedCopy-->
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.
De forma predeterminada, los hosts de XenServer pertenecen a un grupo sin nombre. 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-->
XenServer simplifica la expansión de las implementaciones a lo largo del tiempo al permitir que hardware de host dispares se una a un grupo de recursos, conocido 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 hosts XenServer 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 anfitriones sean del mismo tipo a nivel de familia, modelo o números escalonados.
XenServer 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. Al mover o migrar una máquina virtual a un host diferente dentro o entre grupos, XenServer compara el conjunto de funciones de la máquina virtual con el conjunto de funciones del host de destino. Si se determina que los conjuntos de funciones son compatibles, se permite la migración de la máquina virtual. Esto permite que la máquina virtual se mueva libremente dentro 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.
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.
Abra una consola en cualquier host XenServer 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
<!--NeedCopy-->
device-config:server es el nombre de host del servidor NFS y device-config:serverpath es la ruta del servidor NFS. Si shared 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 adelante 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
<!--NeedCopy-->
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-->
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.
Nota:
Antes de eliminar cualquier host de XenServer 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 hosts XenServer de un grupo si hay datos importantes en los discos locales.
Abra una consola en cualquier host del grupo.
Busque el UUID del host ejecutando el siguiente comando:
xe host-list
<!--NeedCopy-->
Expulse el host requerido del grupo:
xe pool-eject host-uuid=host_uuid
<!--NeedCopy-->
El host XenServer 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-copyde la CLI.
Cuando los hosts 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 hayan cambiado para que apunten al almacenamiento compartido visto por otros hosts de XenServer del grupo o se hayan eliminado. Por lo tanto, le recomendamos que traslade cualquier almacenamiento local a un almacenamiento compartido cuando se una a un grupo. Pasar a un almacenamiento compartido permite expulsar (o fallar físicamente) los hosts individuales de XenServer 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.
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 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 reserva se produce cada 24 horas. Al poner el coordinador del grupo en modo de mantenimiento, se pierden las últimas 24 horas de actualizaciones de RRD para las máquinas virtuales sin conexión.
Advertencia:
Recomendamos encarecidamente reiniciar todos los hosts de XenServer antes de instalar una actualización y comprobar su configuración. Algunos cambios de configuración solo se aplican cuando se reinicia el host de XenServer, por lo que el reinicio puede detectar problemas de configuración que pueden provocar un error en la actualización.
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.
Realice la operación de mantenimiento deseada.
Habilite el host XenServer cuando se complete la operación de mantenimiento:
xe host-enable
<!--NeedCopy-->
Reinicie las máquinas virtuales detenidas y reanude las máquinas virtuales suspendidas.
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 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:
La exportación de datos de la agrupación 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:
Redes:
VDI:
Almacenamiento:
VM:
GPU:
Nota:
La información sobre las GPU solo está disponible si hay GPU conectadas al host de XenServer.
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.
Puede usar la función de encendido del host de XenServer para encender y apagar 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.
Tarjetas de acceso remoto de Dell (DRAC). Para usar XenServer con DRAC, debe instalar el paquete complementario de Dell para obtener soporte para DRAC. La compatibilidad con la DRAC requiere instalar la utilidad de línea de comandos RACADM en el host con la controladora de acceso remoto y habilitar la 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 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 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.
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 XenServer).
Después de habilitar el encendido del host, puede activar los hosts mediante la CLI o XenCenter.
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.
Ejecute el comando:
xe host-power-on host=<host uuid>
<!--NeedCopy-->
Si la solución de alimentación remota de su anfitrión utiliza un protocolo que no es compatible de forma predeterminada (como Wake-On-Ring o la tecnología Intel Active Management), puede crear un script Python de Linux personalizado para encender los equipos XenServer 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 XenServer. host.power_on
Cuando cree un script personalizado, ejecútelo desde la línea de comandos cada vez que quiera controlar la alimentación de forma remota en un host de XenServer. Como alternativa, puede especificarlo en XenCenter y usar las funciones de la interfaz de usuario de XenCenter para interactuar con él.
La API de XenServer está documentada en la API de administración de XenServer.
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.
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-->
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
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)
El script de ejemplo importa la API de XenServer, se define como un script personalizado y, a continuación, pasa parámetros específicos del 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.
XenServer usa 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 de los clientes en la funcionalidad criptográfica del producto.
XenServer usa el siguiente conjunto de cifrado:
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:
Cuando se utiliza un cliente SSH para conectarse directamente al host de XenServer, se pueden utilizar los siguientes algoritmos:
Cifrados:
MAC:
KexAlgorithms:
HostKeyAlgorithms:
Si quiere inhabilitar el acceso SSH a su host de XenServer, puede hacerlo en. xsconsole
root
xsconsole.En xsconsole, vaya a Configuración de servicio remoto > Habilitar/inhabilitar Shell remoto.
La consola muestra si el shell remoto está habilitado.
Importante:
No admitimos modificaciones por parte de los clientes en la funcionalidad criptográfica del producto.
El host 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 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:
.pem o .key..pem, .cer o .crt.La CLI de xe le avisa cuando el certificado y la clave que elija no cumplen con estos requisitos.
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 host de XenServer y no copiarse de un sistema a otro.
La creación de un certificado TLS tiene los siguientes pasos:
En primer lugar, genere una solicitud de firma de certificado y clave privada. En el host de XenServer, complete los siguientes pasos:
Para crear un archivo de clave privada, ejecute el siguiente comando:
openssl genrsa -des3 -out privatekey.pem 2048
<!--NeedCopy-->
Se le pedirá que introduzca una contraseña. Esta frase de contraseña se elimina en un paso siguiente.
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
<!--NeedCopy-->
Siga las instrucciones para proporcionar la información necesaria para generar la solicitud de firma de certificado.
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
<!--NeedCopy-->
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-->
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:
Ahora puede instalar todos estos archivos en el host de XenServer.
Una vez que la entidad de certificación haya respondido a la solicitud de firma del certificado, complete los siguientes pasos para instalar el certificado en el host de XenServer:
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 parámetro certificate-chain es opcional.
Para mayor seguridad, puede eliminar el archivo de clave privada después de instalar el certificado.
Cuando instala por primera vez un host de XenServer, establece una contraseña de administrador o root. Use esta contraseña para conectar XenCenter a su host o (con el rootnombre de usuario) para iniciar sesión enxsconsole, la consola de configuración del sistema.
Si une un anfitrión 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:
Las contraseñas de administrador de XenServer solo deben contener caracteres ASCII.
Puede usar XenCenter, la CLI de xe o xsconsole para cambiar la contraseña del administrador.
Para cambiar la contraseña de administrador de un grupo o un host independiente mediante XenCenter, complete los siguientes pasos:
Para cambiar la contraseña raíz de un host independiente, seleccione el host en el panel Recursos, 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 host entre sesiones, se recuerda la nueva contraseña. Para obtener más información, consulte Almacenar el estado de la conexión del host.
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.
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:
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.
Para cambiar la contraseña de administrador de un grupo o un host independiente mediante xsconsole, complete los siguientes pasos:
root.xsconsole. Presiona Entrar. Se muestra xsconsole.Aparecerá la pantalla Cambio de contraseña correcto. Presione Entrar para cerrarla.
Si el anfitrión 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, rote el secreto del grupo. Para obtener más información, consulte Rotar el secreto de la agrupación.
Si pierde la contraseña de administrador (root) del host de XenServer, puede restablecerla accediendo directamente al host.
Reinicie el host de XenServer.
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 anfitrión 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, rote el secreto del grupo.
El secreto de la agrupación es un secreto compartido entre los anfitriones de una agrupación que permite al anfitrión demostrar su pertenencia a una agrupación.
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.
Para rotar el secreto del grupo de un grupo mediante XenCenter, siga estos pasos:
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.
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 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.
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 obligarlos a procesar 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. De lo contrario, la multidifusión en la subred recurre a la transmisión y puede reducir 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 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.
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.
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 serxenbr0,xenbr1,xenapioxapi0.
Esto genera una tabla con cuatro columnas:
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.
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á inhabilitada de forma predeterminada, pero se puede cambiar mediante XenCenter o la CLI xe. Para obtener más información, consulte Propiedades de la agrupación: Opciones avanzadas y Parámetros de la agrupación. 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 el comando vm-migrate en Comandos de máquina virtual.