¿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): isoPodemos 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-d45a79d9bae8Si 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/lvmbackupVamos 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): trueNos 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/nvme1n1Ya 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-a8fc7e210059Luego desconectamos el SR en LVM:
xe sr-forget uuid=1718f257-2630-a7c4-7667-6fa4c295feePara 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-6fa4c295feefTenemos 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-d45a79d9bae8Hay 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-d45a79d9bae8Vamos 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-6197ae89df3cY 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-d45a79d9bae8Si 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-d45a79d9bae8Podemos revisar si los VDI son visibles:
# xe vdi-list sr-uuid=f4f3ceec-bce3-e42d-998d-d45a79d9bae8Ahora 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
Deja una respuesta