• Saltar a la navegación principal
  • Saltar al contenido principal
  • Saltar a la barra lateral principal

Joan Escorihuela

  • Inicio
  • Contacto

10 diciembre, 2019 by Joan Deja un comentario

Restaurar un Storage Repository (SR) LVM borrado en XenServer

¿Has quitado un host de XenServer o XCP-NG de una Pool y te has quedado sin los datos del Storage Repository? Aunque parezca una broma maligna de Xen esto ocurre cuando tienes las maquinas virtuales en el repositorio local de un hypervisor Xen en una Pool y quieres sacar este de la misma.

No te preocupes, pues existe solución para ello, siempre y cuando no hayas añadido datos al nuevo Storage Repository que te crea el Hypervisor, esta solución es en muchas ocasiones más rápida que hacer restauración de una copia de las maquinas virtuales y recuperas el estado original justo en el momento del desastre.

Lo primero que hay que hacer es relajarse, pocas situaciones hay en el mundo de la visualización que no se puedan solucionar y esta no es una de ellas.

En primer lugar hay que acceder al host mediante SSH para desmontar el repositorio actual que nos ha creado, aunque parezca el mismo en realidad no lo es, ya que tiene un sr-uuid distinto al original.

Para ver los actuales hay que ejecutar xe-srlist y nos va aparecer algo como esto:

# xe sr-list

uuid ( RO)                : 99ef9b81-21dc-7f8d-7c69-24a349e6db5f
          name-label ( RW): hv01
    name-description ( RW): 
                host ( RO): hv01
                type ( RO): lvm
        content-type ( RO): user


uuid ( RO)                : 1718f257-2630-a7c4-7667-6fa4c295feef
          name-label ( RW): sr-local
    name-description ( RW): 
                host ( RO): hv01
                type ( RO): lvm
        content-type ( RO): user


uuid ( RO)                : 546247ac-dc76-fbcb-2c05-d4b74ccbad46
          name-label ( RW): sr-backups
    name-description ( RW): SMB SR [\\x.x.x.x\backup\xen]
                host ( RO): <shared>
                type ( RO): smb
        content-type ( RO): 


uuid ( RO)                : ac302462-b59a-5da2-8dee-a844be7c23e9
          name-label ( RW): xcp-tools
    name-description ( RW): XCP-ng Tools ISOs
                host ( RO): <shared>
                type ( RO): iso
        content-type ( RO): iso

Podemos ver que en este caso hay un repositorio local con el uuid 1718f257-2630-a7c4-7667-6fa4c295fee este se ha generado al sacar la maquina de la Pool, así que tenemos que buscar el nombre del antiguo Storage Repository. Periodicamente se genera una copia de la configuración del LVM en /etc/lvm/backup

# ls -l /etc/lvm/backup
total 16
-rw------- 1 root root 1630 dic  6 19:18 VG_XenStorage-1718f257-2630-a7c4-7667-6fa4c295feef
-rw------- 1 root root 9208 dic  6 19:18 VG_XenStorage-f4f3ceec-bce3-e42d-998d-d45a79d9bae8

Si la copia está al día vamos a ver el repositorio nuevo con el nuevo uuid y el antiguo con su correspondiente uuid.
Por seguridad, vamos hacer una copia de estos ficheros, ya que son necesarios para volver a levantar el SR.

# mkdir /root/lvmbackup
# cp /etc/lvm/backup/* /root/lvmbackup

Vamos a recopilar información que sera necesaria más adelante:
host-uuid y device-config

# xe pbd-list sr-uuid=1718f257-2630-a7c4-7667-6fa4c295fee
uuid ( RO)                  : 12de0ba4-be12-68a8-7c6f-a8fc7e210059
             host-uuid ( RO): bcd7ffe9-3c6e-4684-8803-6197ae89df3c
               sr-uuid ( RO): 1718f257-2630-a7c4-7667-6fa4c295fee
         device-config (MRO): device: /dev/nvme0n1p3,/dev/nvme1n1
    currently-attached ( RO): true

Nos vamos a quedar con estos datos:

uuid ( RO)                  : 12de0ba4-be12-68a8-7c6f-a8fc7e210059         
     host-uuid ( RO): bcd7ffe9-3c6e-4684-8803-6197ae89df3c
     device-config (MRO): device: /dev/nvme0n1p3,/dev/nvme1n1

Ya tenemos recopilada toda la información necesaria, el uuid del antiguo y nuevo SR, el uuid del host y la device-config y el uuid del pbd, por lo que podemos desconectar el SR actual. Primero desconectamos el PBD:

# xe pbd-unplug uuid=12de0ba4-be12-68a8-7c6f-a8fc7e210059

Luego desconectamos el SR en LVM:

xe sr-forget uuid=1718f257-2630-a7c4-7667-6fa4c295fee

Para conectar de nuevo el antiguo SR, hay que modificar el fichero del antiguo SR, tan solo hay que modificar las lineas de los identificadores del Phisical Volumes. Debemos poner los identificadores del nuevo SR, en el fichero del antiguo SR, así que en primer lugar vamos a revisar la configuración del nuevo SR:

nano /etc/lvm/backup/VG_XenStorage-1718f257-2630-a7c4-7667-6fa4c295feef

Tenemos que buscar esto:

physical_volumes {

                pv0 {
                     	id = "drLb4e-naAb-2wVH-GLAN-BzkN-fdaZ-ImYRI1"
                        device = "/dev/nvme0n1p3"	# Hint only

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 913181327    # 435.439 Gigabytes
                        pe_start = 22528
                        pe_count = 111469	# 435.426 Gigabytes
                }

                pv1 {
                     	id = "bBKasV-vN2c-RUG0-XysS-0JDo-CfRR-V4hsuN"
                        device = "/dev/nvme1n1" # Hint only

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 1000215216   # 476.94 Gigabytes
                        pe_start = 22528
                        pe_count = 122093	# 476.926 Gigabytes
                }
        }

Dependiendo de la configuración del LVM, vamos a tener uno o varios identificadores (uno por cada disco físico) nos los anotamos y modificamos la configuración del antiguo LVM

nano /etc/lvm/backup/VG_XenStorage-f4f3ceec-bce3-e42d-998d-d45a79d9bae8

Hay que modificar las siguientes lineas:

pv0 {
     id = "LhitjD-2tpu-SK0X-rCnl-mxiG-AqHu-wXWo2L"

Por:

pv0 {
     id = "drLb4e-naAb-2wVH-GLAN-BzkN-fdaZ-ImYRI1"

Y

 pv1 {
      id = "cW1qkF-rJ0V-b6mN-ksDS-C3zt-s1ck-ldfT45"

Por:

 pv1 {
      id = "bBKasV-vN2c-RUG0-XysS-0JDo-CfRR-V4hsuN"

Podemos guardar los cambios en el fichero. Con este cambio permitimos levantar el antiguo volumen LVM en los nuevos identificadores generados para los discos físicos. Ahora vamos a restaurar el LVM con vgcfgrestore:
Recomiendo usar el modificador –test antes de realizar la recuperación:

# vgcfgrestore --test VG_XenStorage-f4f3ceec-bce3-e42d-998d-d45a79d9bae8 -f /etc/lvm/backup/VG_XenStorage-f4f3ceec-bce3-e42d-998d-d45a79d9bae8 --config global{metadata_read_only=0}

Si ha ido bien lo podemos ejecutar sin el modificador –test

# vgcfgrestore VG_XenStorage-f4f3ceec-bce3-e42d-998d-d45a79d9bae8 -f /etc/lvm/backup/VG_XenStorage-f4f3ceec-bce3-e42d-998d-d45a79d9bae8 --config global{metadata_read_only=0}

Una vez hecho si ejecutamos pvscan podemos ver que se ha creado el LVM con el antiguo uuid

# pvscan
  PV /dev/nvme0n1p3   VG VG_XenStorage-f4f3ceec-bce3-e42d-998d-d45a79d9bae8   lvm2 [435,43 GiB / 4,00 MiB free]
  PV /dev/nvme1n1     VG VG_XenStorage-f4f3ceec-bce3-e42d-998d-d45a79d9bae8   lvm2 [476,93 GiB / 3,93 GiB free]

Ahora vamos a registrar el SR en Xen usando el antiguo uuid:

# xe sr-introduce uuid=f4f3ceec-bce3-e42d-998d-d45a79d9bae8 type=lvm name-label=”dshvhe03” content-type=user
f4f3ceec-bce3-e42d-998d-d45a79d9bae8

Vamos a crear el PBD, aquí vamos a necesitar el host uuid y el device-config que nos anotamos al principio:

xe pbd-create sr-uuid=f4f3ceec-bce3-e42d-998d-d45a79d9bae8 device-config:device=/dev/nvme0n1p3,/dev/nvme1n1 host-uuid=bcd7ffe9-3c6e-4684-8803-6197ae89df3c

Y por último conectamos el PBD al host, para que este pueda acceder a los VDI del SR, tal y como estaban justo antes de ser reemplazado:

# xe pbd-plug uuid=f4f3ceec-bce3-e42d-998d-d45a79d9bae8

Si todo ha ido bien vamos a ver el antiguo SR conectado al host:

# xe pbd-list sr-uuid=f4f3ceec-bce3-e42d-998d-d45a79d9bae8
uuid ( RO)                  : 12de0ba4-be12-68a8-7c6f-a8fc7e210059
             host-uuid ( RO): bcd7ffe9-3c6e-4684-8803-6197ae89df3c
               sr-uuid ( RO): f4f3ceec-bce3-e42d-998d-d45a79d9bae8
         device-config (MRO): device: /dev/nvme0n1p3,/dev/nvme1n1
    currently-attached ( RO): true

Si no vemos los VDI, es que aún hay que escanear el contenido del SR:

# xe sr-scan uuid=f4f3ceec-bce3-e42d-998d-d45a79d9bae8

Podemos revisar si los VDI son visibles:

# xe vdi-list sr-uuid=f4f3ceec-bce3-e42d-998d-d45a79d9bae8

Ahora ya podemos crear nuevas máquinas virtuales y hacer un Attach de los VDI que nos interesan. Si las máquinas tenien uno o varios Snapshot, hay que verificar a que VDI hay que conectarnos, ya que deberíamos hacerlo en el último, podemos verificar cual es el VDI apropiado revisando los Snapshots con vhd-util:

# vhd-util scan -f -a -c -m "VHD-*" -l VG_XenStorage-f4f3ceec-bce3-e42d-998d-d45a79d9bae8 -p
vhd=VHD-6fcc4382-7880-42f9-9ffe-25531f5af2a5 capacity=483183820800 size=420458004480 hidden=1 parent=none
   vhd=VHD-bc56574a-5403-4290-83e5-0e39330006b8 capacity=483183820800 size=8388608 hidden=0 parent=VHD-6fcc4382-7880-42f9-9ffe-25531f5af2a5
   vhd=VHD-601c7259-0cb2-4a25-9694-28da41695e9d capacity=483183820800 size=18660458496 hidden=1 parent=VHD-6fcc4382-7880-42f9-9ffe-25531f5af2a5
      vhd=VHD-a6be516b-add6-4837-97d7-97860e920d8e capacity=483183820800 size=8388608 hidden=0 parent=VHD-601c7259-0cb2-4a25-9694-28da41695e9d
      vhd=VHD-432918f5-9399-4a7a-9e80-ac0c471f111b capacity=483183820800 size=20992491520 hidden=1 parent=VHD-601c7259-0cb2-4a25-9694-28da41695e9d
         vhd=VHD-34a10034-ed4d-47e1-88fc-2725d8da92e0 capacity=483183820800 size=8388608 hidden=0 parent=VHD-432918f5-9399-4a7a-9e80-ac0c471f111b
         vhd=VHD-95a37458-42c2-46b7-a2a6-e68ff77cac36 capacity=483183820800 size=14923333632 hidden=1 parent=VHD-432918f5-9399-4a7a-9e80-ac0c471f111b
            vhd=VHD-fb3b40ea-407f-4122-a127-02c706754c05 capacity=483183820800 size=8388608 hidden=0 parent=VHD-95a37458-42c2-46b7-a2a6-e68ff77cac36
            vhd=VHD-3a314651-5665-42cf-99f0-1f8b43e64a15 capacity=483183820800 size=16194207744 hidden=1 parent=VHD-95a37458-42c2-46b7-a2a6-e68ff77cac36
               vhd=VHD-480a3f1d-44b7-4ad6-9df9-da3ca717fecf capacity=483183820800 size=484135927808 hidden=0 parent=VHD-3a314651-5665-42cf-99f0-1f8b43e64a15

En este caso deberíamos hacer Attach del VHD-480a3f1d-44b7-4ad6-9df9-da3ca717fecf ya que es el último.

Si al encender la maquina, esta nos da algún error, podemos revisar el log del Storage Manager:

# tail -f /var/log/SMlog

Publicado en: General

Interacciones con los lectores

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

sidebar

sidebar-alt

Joan Escorihuela ·
  • Política de cookies
  • Aviso legal
  • Contacto