Citrix Hypervisor

Hacer frente a las fallas de la máquina

En esta sección se proporcionan detalles sobre cómo recuperarse de varios casos de error. Todos los casos de recuperación de errores requieren el uso de uno o varios de los tipos de copia de seguridad enumerados en Copia de seguridad.

Fallos de miembros

En ausencia de HA, los nodos maestros detectan las fallas de los miembros al recibir mensajes de latido 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 muerto (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 comandoxe host-forget CLI. Una vez olvidado el miembro, todas las máquinas virtuales que se ejecutaban allí se marcarán como sin conexión y se pueden reiniciar en otros servidores Citrix Hypervisor.

    Es importante asegurarse de que el servidor Citrix Hypervisor esté realmente fuera de línea; de lo contrario, podrían producirse daños en los datos de VM.

    No dividir el grupo en varios grupos de un solo host mediantexe host-forget. Esta acción puede provocar que todos ellos mapeen el mismo almacenamiento compartido y dañen los datos de VM.

Advertencia:

  • Si va a volver a utilizar el host olvidado como host activo, realice una nueva instalación del software Citrix Hypervisor.
  • No ejecute el comando xe host-forget si HA está habilitado en el grupo. Inhabilite primero HA, luego olvide el host y, a continuación, vuelva a habilitar HA.

Cuando falla un servidor miembro de Citrix Hypervisor, es posible que haya máquinas virtuales todavía registradas en el estado de ejecución. Si está seguro de que el servidor miembro de Citrix Hypervisor está definitivamente inactivo, utilice el comandoxe vm-reset-powerstate CLI para establecer el estado de energía de las máquinas virtuales en halted. Para obtener más información, consulte el apartado vm-reset-powerstate.

Advertencia:

El uso incorrecto de este comando puede provocar daños en los datos. Utilice este comando solo si es necesario.

Antes de iniciar máquinas virtuales en otro servidor Citrix Hypervisor, también es necesario liberar los bloqueos en el almacenamiento de VM. Solo en el host a la vez puede usar cada disco en un SR. Es clave hacer que el disco sea accesible a otros servidores Citrix Hypervisor una vez que un host haya fallado. Para ello, ejecute la siguiente script en el maestro de grupo para cada SR que contenga discos de cualquier VM afectada:/opt/xensource/sm/resetvdis.py host_UUID SR_UUID master

Solo necesita proporcionar la tercera cadena (“master”) 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á caído antes de ejecutar este comando. El uso incorrecto de este comando puede provocar daños en los datos.

Si intenta iniciar una VM en otro servidor Citrix Hypervisor antes de ejecutar la resetvdis.py script, recibirá el siguiente mensaje de error:VDI <UUID> already attached RW.

Fallos maestros

Cada miembro de una agrupación 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 maestro, se produce la siguiente secuencia de eventos:

  1. Si HA está activada, se elige automáticamente otro maestro.

  2. Si HA no está habilitada, cada miembro espera a que regrese el maestro.

Si el maestro vuelve a aparecer 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 comandoxe pool-emergency-transition-to-master en él. Una vez que se haya convertido en el maestro, ejecute el comandoxe pool-recover-slaves y los miembros ahora apuntan al nuevo patrón.

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 Citrix Hypervisor del grupo se imponen para que sean homogéneos, no hay necesidad real de convertir el servidor reemplazado en el maestro.

Cuando un servidor miembro de Citrix Hypervisor pasa a ser maestro, compruebe que el repositorio de almacenamiento de grupo predeterminado esté establecido en un valor adecuado. Esta comprobación se puede realizar mediante el comando xe pool-param-list y verificar que el parámetro default-SR apunta a un repositorio de almacenamiento válido.

Fallas del grupo

En el desafortunado caso de que falle toda la agrupación de recursos, debe volver a crear la base de datos del grupo desde cero. Asegúrese de realizar una copia de seguridad periódica de los metadatos del grupo mediante el comandoxe pool-dump-database CLI (consulte pool-dump-database).

Para restaurar un grupo completamente fallido:

  1. Instale un nuevo conjunto de hosts. No los ponga en común en esta etapa.

  2. Para el host designado como maestro, restaure la base de datos del grupo a partir de la copia de seguridad mediante el comando xe pool-restore-database (consulte agrupación-restore-base de datos).

  3. Conéctese al host principal mediante XenCenter y asegúrese de que todas las máquinas virtuales y almacenamiento compartido estén disponibles de nuevo.

  4. Realice una operación de unión de grupo en los hosts miembros recién instalados restantes e inicie las máquinas virtuales en los hosts apropiados.

Hacer frente a fallos debidos a errores de configuración

Si el equipo host físico está operativo pero la configuración del software o del host está dañada:

  1. Ejecute el siguiente comando para restaurar la configuración y el software del host:

    xe host-restore host=host file-name=hostbackup
    
  2. Reinicie en el CD de instalación del host y seleccione Restaurar desde copia de seguridad.

Fallo físico de la máquina

Si el equipo host físico ha fallado, utilice el procedimiento adecuado de la siguiente lista para recuperar.

Advertencia:

las máquinas virtuales que se ejecutan en un miembro anterior (o en el host anterior) que hayan fallado siguen marcadas comoRunning en la base de datos. Este comportamiento es por seguridad. Al iniciar simultáneamente una máquina virtual en dos hosts diferentes, se produciría una grave corrupción 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 alimentación de la máquina virtual aHalted: Las máquinas

xe vm-reset-powerstate vm=vm_uuid --force

virtuales se pueden reiniciar mediante XenCenter o la CLI.

Para reemplazar un maestro con errores por un miembro en ejecución:

  1. Ejecute los comandos siguientes:

    xe pool-emergency-transition-to-master
    xe pool-recover-slaves
    
  2. Si los comandos se ejecutan correctamente, reinicie las máquinas virtuales.

Error al restaurar un grupo con todos los hosts:

  1. Ejecute el comando:

    xe pool-restore-database file-name=backup
    

    Advertencia:

    Este comando solo se ejecuta correctamente si el equipo de destino tiene un número adecuado de NIC con nombre apropiado.

  2. Si la máquina de destino tiene una vista diferente del almacenamiento que la máquina original, modifique la configuración de almacenamiento mediante el comando pbd-destroy. A continuación, ejecute el comando pbd-create para volver a crear configuraciones de almacenamiento. Consulte comandos pbd para obtener documentación de estos comandos.

  3. Si ha creado una configuración de almacenamiento, utilicepbd-plug el elemento de menú Almacenamiento > Reparar repositorio de almacenamiento de XenCenter para utilizar la nueva configuración.

  4. Reinicie todas las máquinas virtuales.

Para restaurar una VM cuando el almacenamiento de VM no está disponible:

  1. Ejecute el comando siguiente:

    xe vm-import filename=backup metadata=true
    
  2. Si se produce un error en la importación de metadatos, ejecute el comando:

    xe vm-import filename=backup metadata=true --force
    

    Este comando intenta restaurar los metadatos de la máquina virtual sobre la base del “mejor esfuerzo”.

  3. Reinicie todas las máquinas virtuales.

Hacer frente a las fallas de la máquina