Hacer frente a los fallos de las máquinas
Importante:
La actualización acumulativa 1 de Citrix Hypervisor 8.2 llega al final de su vida útil el 25 de junio de 2025. Planifique su actualización a XenServer 8 ahora para garantizar una transición fluida y un soporte continuo. Para obtener más información, consulte Actualizar.
Si utiliza los archivos de licencia de Citrix Virtual Apps and Desktops para licenciar los hosts de Citrix Hypervisor 8.2 Cumulative Update 1, estos archivos de licencia no son compatibles con XenServer 8. Antes de actualizar, debe adquirir los archivos de licencia de socket de XenServer Premium Edition para utilizarlos con XenServer 8. Estos archivos de licencia de socket están disponibles como un derecho de las suscripciones de Citrix para Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP y Citrix Platform License para ejecutar sus cargas de trabajo de Citrix. Los clientes de Citrix que aún no hayan realizado la transición a estas nuevas suscripciones pueden solicitar participar en una promoción gratuita de 10.000 licencias de socket de XenServer Premium Edition. Para obtener más información, consulte XenServer.
Si no obtiene una licencia compatible para XenServer 8 antes de actualizar, cuando actualice sus hosts, estos volverán a la edición de prueba de 90 días. La Edición de Prueba ofrece las mismas características que la Edición Premium con algunas limitaciones. Para obtener más información, consulte Descripción general de las licencias de XenServer 8.
En esta sección se proporcionan detalles sobre cómo recuperarse de varios escenarios de error. Todos los escenarios de recuperación de errores requieren el uso de uno o varios de los tipos de copia de seguridad enumerados en Copia de seguridad.
Errores de miembros
En ausencia de alta disponibilidad, los nodos maestros detectan los errores de los miembros mediante la recepción de mensajes de latidos regulares. Si no se ha recibido ningún latido durante 600 segundos, el maestro asume que el miembro está muerto. Hay dos formas de recuperarse de este problema:
-
Repare el host inactivo (por ejemplo, reiniciándolo físicamente). Cuando se restablece la conexión con el miembro, el maestro marca el miembro como activo de nuevo.
-
Apague el host e indique al maestro que se olvide del nodo miembro mediante el comando
xe host-forgetComando CLI. Una vez que se ha olvidado el miembro, todas las máquinas virtuales que se estaban ejecutando allí se marcan como sin conexión y se pueden reiniciar en otros servidores de Citrix Hypervisor.Es importante asegurarse de que el servidor de Citrix Hypervisor esté realmente sin conexión, de lo contrario, podrían producirse daños en los datos de la máquina virtual.
No divida el grupo en varios grupos de un solo host mediante el uso de
xe host-forget. Esta acción puede dar lugar a que todos ellos asignen el mismo almacenamiento compartido y dañen los datos de la máquina virtual.
Advertencia:
- Si va a volver a utilizar el host olvidado como host activo, realice una instalación nueva del software Citrix Hypervisor.
- No utilizar
xe host-forgetsi HA está habilitado en el grupo. Deshabilite primero HA, luego olvide el host y, a continuación, vuelva a habilitar HA.
Cuando se produce un error en un servidor Citrix Hypervisor miembro, es posible que aún haya máquinas virtuales registradas en el corriente estado. Si está seguro de que el servidor Citrix Hypervisor miembro está definitivamente inactivo, utilice el xe vm-reset-powerstate CLI para establecer el estado de energía de las máquinas virtuales en detenido. Ver vm-reset-powerstate para más detalles.
Advertencia:
El uso incorrecto de este comando puede provocar daños en los datos. Utilice este comando solo si es necesario.
Antes de poder iniciar máquinas virtuales en otro servidor de Citrix Hypervisor, también debe liberar los bloqueos en el almacenamiento de máquinas virtuales. Solo en el host a la vez puede usar cada disco en un SR. Es clave hacer que el disco sea accesible para otros servidores de Citrix Hypervisor una vez que un host ha fallado. Para ello, ejecute el siguiente script en el maestro de grupo para cada SR que contenga discos de las máquinas virtuales afectadas: /opt/xensource/sm/resetvdis.py host_UUID SR_UUID maestro
Solo necesita proporcionar la tercera cadena (“maestro”) si el host fallido era el maestro SR en el momento del bloqueo. (El maestro SR es el maestro de grupo o un servidor Citrix Hypervisor que utiliza almacenamiento local).
Advertencia:
Asegúrese de que el host esté inactivo antes de ejecutar este comando. El uso incorrecto de este comando puede provocar daños en los datos.
Si intenta iniciar una máquina virtual en otro servidor de Citrix Hypervisor antes de ejecutar el resetvdis.py script, recibirá el siguiente mensaje de error: VDI <UUID> RW ya montado.
Errores de maestro
Cada miembro de un grupo de recursos contiene toda la información necesaria para asumir el rol de maestro si es necesario. Cuando se produce un error en un nodo principal, se produce la siguiente secuencia de eventos:
-
Si HA está habilitado, se elige automáticamente otro maestro.
-
Si HA no está habilitado, cada miembro espera a que regrese el maestro.
Si el maestro vuelve a subir en este punto, restablece la comunicación con sus miembros y la operación vuelve a la normalidad.
Si el maestro está muerto, elija uno de los miembros y ejecute el comando xe pool-emergency-transition-to-master en él. Una vez que se haya convertido en el maestro, ejecute el comando xe pool-recover-slaves Y los miembros ahora señalan al nuevo maestro.
Si repara o reemplaza el servidor que era el maestro original, simplemente puede abrirlo, instalar el software Citrix Hypervisor y agregarlo al grupo. Dado que los servidores de Citrix Hypervisor en el grupo se aplican para ser homogéneos, no hay necesidad real de hacer que el servidor reemplazado sea el maestro.
Cuando se realiza la transición de un servidor Citrix Hypervisor miembro a ser un maestro, compruebe que el repositorio de almacenamiento del grupo predeterminado esté establecido en un valor adecuado. Esta comprobación se puede realizar mediante el método xe pool-param-list comando y verificando que el predeterminado-SR apunta a un repositorio de almacenamiento válido.
Errores de la piscina
En el desafortunado caso de que se produzca un error en todo el grupo de recursos, debe volver a crear la base de datos del grupo desde cero. Asegúrese de hacer una copia de seguridad periódica de los metadatos del grupo mediante el método xe pool-dump-database CLI (consulte base de datos-de-volcado-de-pool).
Para restaurar un grupo con errores completos:
-
Instale un nuevo conjunto de hosts. No los acumule en esta etapa.
-
Para el host designado como maestro, restaure la base de datos del grupo a partir de la copia de seguridad mediante el método
xe pool-restore-database(véase pool-restore-database). -
Conéctese al host principal mediante XenCenter y asegúrese de que todo el almacenamiento compartido y las máquinas virtuales vuelvan a estar disponibles.
-
Realice una operación de unión al grupo en los hosts miembro recién instalados restantes e inicie las máquinas virtuales en los hosts adecuados.
Hacer frente a fallos debidos a errores de configuración
Si el equipo host físico está operativo, pero el software o la configuración del host están dañados:
-
Ejecute el siguiente comando para restaurar el software y la configuración del host:
xe host-restore host=host file-name=hostbackup <!--NeedCopy--> -
Reinicie el CD de instalación del host y seleccione Restaurar desde copia de seguridad.
Falla física de la máquina
Si se ha producido un error en el equipo host físico, utilice el procedimiento adecuado de la siguiente lista para recuperarlo.
Advertencia:
Las máquinas virtuales que se ejecutan en un miembro anterior (o en el host anterior) que hayan fallado siguen marcadas como
Corrienteen la base de datos. Este comportamiento es por seguridad. El inicio simultáneo de una máquina virtual en dos hosts diferentes provocaría daños graves en el disco. Si está seguro de que las máquinas (y las máquinas virtuales) están sin conexión, puede restablecer el estado de energía de la máquina virtual aDetenido:
xe vm-reset-powerstate vm=vm_uuid --forceA continuación, las máquinas virtuales se pueden reiniciar mediante XenCenter o la CLI.
Para reemplazar un maestro con errores por un miembro que aún se está ejecutando:
-
Ejecute los comandos siguientes:
xe pool-emergency-transition-to-master xe pool-recover-slaves <!--NeedCopy--> -
Si los comandos se ejecutan correctamente, reinicie las máquinas virtuales.
Para restaurar un grupo con errores en todos los hosts:
-
Ejecute el comando:
xe pool-restore-database file-name=backup <!--NeedCopy-->Advertencia:
Este comando solo se ejecuta correctamente si el equipo de destino tiene un número adecuado de NIC con el nombre adecuado.
-
Si el equipo de destino tiene una vista del almacenamiento diferente a la del equipo original, modifique la configuración de almacenamiento mediante el comando
pbd-destruirmandar. A continuación, utilice el métodopbd-createpara volver a crear configuraciones de almacenamiento. Ver Comandos pbd para la documentación de estos comandos. -
Si ha creado una configuración de almacenamiento, utilice
Enchufe PBDo Almacenamiento > Reparar repositorio de almacenamiento en XenCenter para usar la nueva configuración. -
Reinicie todas las máquinas virtuales.
Para restaurar una máquina virtual cuando el almacenamiento de la máquina virtual no está disponible:
-
Ejecute este comando:
xe vm-import filename=backup metadata=true <!--NeedCopy--> -
Si se produce un error en la importación de metadatos, ejecute el comando:
xe vm-import filename=backup metadata=true --force <!--NeedCopy-->Este comando intenta restaurar los metadatos de la máquina virtual en la medida de lo posible.
-
Reinicie todas las máquinas virtuales.