Como reinstalar xen server y preservar las maquinas virtuales en el Local storage

La semana pasada me paso que el XenServer de mi trabajo se le reventó un disco duro. No se que fue, pero quedo roto el disco duro justo del sistema operativo xen. 

Eran dos discos y estaban con raid 1. Recupere el raid colocando un disco duro nuevo, y realizando las configuraciones necesarias. Enciendo el servidor, y salta un error de xen server:

Cannot load XAPI no se que..

-A buenooo se revento todooo...

Buscando encontré que la base de datos de xen server estaba corrupta.. que bueno. Lo que hice para recuperar el servicio fue renombrar la base vieja y levantar el servicio xapi. Entonces cuando se levanto xapi creo una base nueva. 

xe-toolstack-restart

cd /var/xapi/

ls -al

mv state.db state.db_bak

service xapi restart

Ahí me pude conectar con la consola de xen server, pero no me figuraba ninguno de los servidores, ni tampoco los local storage (El lugar donde están las vm). Justamente los local storage eran unos discos apartes que se encontraban en el servidor. 

Lo que hice básicamente fue seguir este tutorial de xen server:

https://support.citrix.com/article/CTX136342

Con pvscan, escanea todos los phisical volumes:

[root@xenserver dev]# pvscan

  PV /dev/sdb   VG VG_XenStorage-15f8cab5-0a5f-d721-3c8f-288230bba4cd   lvm2 [1.82 TB / 656.44 GB free]

  PV /dev/sdc   VG VG_XenStorage-15f8cab5-0a5f-d721-3c8f-288230bba4cd   lvm2 [1.82 TB / 860.52 GB free]

  Total: 2 [3.64 TB] / in use: 2 [3.64 TB] / in no VG: 0 [0   ]

Y con este comando re introduce el SR en la base de datos de xen server llamándolo "local storage". Fijarse que el uuid indicado es el mismo que el detectado por el pvscan.

[root@xenserver dev]# xe sr-introduce uuid=15f8cab5-0a5f-d721-3c8f-288230bba4cd type=lvm name-label=”Local storage” content-type=user

En este directorio vemos los discos y particiones que hay en el servidor.

[root@xenserver dev]# ll /dev/disk/by-id

total 0

lrwxrwxrwx 1 root root  9 Feb 22 12:34 scsi-36b8ca3a0e9b0fc0019cc2d3465392315 -> ../../sda

lrwxrwxrwx 1 root root 10 Feb 22 12:34 scsi-36b8ca3a0e9b0fc0019cc2d3465392315-part1 -> ../../sda1

lrwxrwxrwx 1 root root 10 Feb 22 12:34 scsi-36b8ca3a0e9b0fc0019cc2d3465392315-part2 -> ../../sda2

lrwxrwxrwx 1 root root  9 Feb 22 12:34 scsi-36b8ca3a0e9b0fc0019cc2dfd712fa3bf -> ../../sdb

lrwxrwxrwx 1 root root  9 Feb 22 12:34 scsi-36b8ca3a0e9b0fc0019cc2e2673a81a1a -> ../../sdc

Con este comando vemos el uuid del host

[root@xenserver dev]# xe host-list

uuid ( RO)                : a860dc97-a6ea-46cd-8eba-fd1b17f5b004

          name-label ( RW): xenserver

    name-description ( RW): Default install of XenServer

Crear el PBD usando el device SCSI ID, host UUID y SR UUID detectados

[root@xenserver dev]# xe pbd-create sr-uuid=15f8cab5-0a5f-d721-3c8f-288230bba4cd device-config:device=/dev/disk/by-id/scsi-36b8ca3a0e9b0fc0019cc2dfd712fa3bf host-uuid=a860dc97-a6ea-46cd-8eba-fd1b17f5b004

f6c5f60f-5903-5cdd-4c5d-8380ba9fe21c

Adjuntar el PBD

[root@xenserver dev]# xe pbd-plug uuid=f6c5f60f-5903-5cdd-4c5d-8380ba9fe21c

Ahora lo que vamos a hacer es crear una vm nueva, sin disco duro, y a esa vm adjuntarle el disco duro de la vm que queríamos restaurar en este caso es Windows Server 2008 (64-bit) 0 . 

Para eso tenemos que ejecutar un comando que asociara la vm con el disco duro. 

Primero ver los uuid de las VM que queremos restaurar, recordarlo.

[root@xenserver xapi]# xe vdi-list

uuid ( RO)                : 494d09b9-0a92-4045-bf41-b22f03dc2b3a

          name-label ( RW): Windows Server 2008 (64-bit) 0

    name-description ( RW): Created by template provisioner

             sr-uuid ( RO): 15f8cab5-0a5f-d721-3c8f-288230bba4cd

        virtual-size ( RO): 268435456000

            sharable ( RO): false

           read-only ( RO): false

Ver el uuid de la VM en la interfaz de xen server. 

Despues ejecutar este comando, donde vdi-uuid es el visto con el comando xe vdi-list y vm-uuid es el visto en la interfaz de xen server.

[root@xenserver xapi]# xe vbd-create vdi-uuid=494d09b9-0a92-4045-bf41-b22f03dc2b3a vm-uuid=2d46141e-d832-e891-b42f-7d4500839c51 type=Disk device=hda bootable=true mode=rw

357aa2f6-7aa1-79ef-5857-53be650c9c09

Para ver todos los templates ejecutamos

/opt/xensource/libexec/create_templates

Fuente:

https://support.citrix.com/article/CTX136342

Inicio automatico xen server 6

Yesterday I finally had some hours left to spare at home to attend to my Homelab. as I’m prepping the environment for my next exam (A19 Citrix XenDesktop 5 Administration) I did wanted to upgrade the XenServers to the latest version. So I spent yesterday evening cleaning up the servers with the old VMs from previous studies and left the two XenApp 6.5 servers and my domain server in place.

Upgrading the XenServer Homelab

The upgrade itself was done easily with the single disk image. This time I was smart enough to learn from my previous mistake, so I brought down any running VMs (even disabled the auto start options to be sure) and started with my Pool Master upgrade,without triggering any Maintenance Mode. The upgrade went smoothly for both servers, so I was quickly up and running again and checking all VM settings.

VM auto start feature

I was a little puzzled on how I could set up my License Server VPX appliance to auto start on booting my XenServer, but I figured it was now set with the vApp features and settings. However the GUI did not offer a select box to enable the auto start feature at the Start Options in the General Properties of the VM. I did not configure HA as it is not necessary right now for my Homelab environment. I just made the assumption that creating and configuring the vApp would enable the auto start feature all the same. And turned off the Homelab servers to test it when I would boot my servers the next day.

Unfortunately for me, it wasn’t that easy this time. As Bill Carovano explains in this post on the Citrix Forums, so design decisions changed the auto start feature availability. As it interfered with the HA, DR and Pool upgrade functionality it was opted out for the XenServer 6 release.

Alternative configuration

For me it still is a very useful feature to ensure my Citrix License Server is automatically started when my XenServer is booted, so luckily for me Bill also gave the right commands to enable the feature with the CLI and have the perfect setup back for my Homelab

You first have to enable the auto power on feature at pool level, before being able to configure it for each VM individually.

* Find the uuid of the Pool:

[root@ ~]# xe pool-list
uuid ( RO) : [uuid-pool]
name-label ( RW): [pool-name]
name-description ( RW): [pool-desc]
master ( RO): [uuid-xs]
default-SR ( RW): [uuid-sr]

 
Which returns the following values:

• uuid-pool: A unique identifier for the Pool.
• pool-name: The name given to the Pool.
• pool-desc: The description set for the Pool.
• uuid-xs: The unique identifier of the XenServer that currently is the Pool Master.
• uuid-sr: The unique identifier for the default Storage Repository configured for the Pool.

* Enable the auto power on feature at pool level:

[root@ ~]# xe pool-param-set uuid=[uuid-pool] other-config:auto_poweron=true

 
Which uses the following additional syntax:

• uuid-pool: A unique identifier for the Pool.

* Find the uuid of the VM:

The quicky way to find the uuid of your VM is to run the vm-list command. This does however give you an overview of all VMs, so if you have alot of VMs defined, try to narrow it done with the name-label parameter (which is case sensitive). With the uuid known for the VM, you can easily enable the auto start feature.

[root@ ~]# xe vm-list
uuid ( RO) : [uuid-vm]
name-label ( RW): [vm-name]
power-state ( RO): [vm-power]

 
Which returns the following values:

• uuid-vm: A unique identifier for the Virtual Machine.
• vm-name: The name given to the Virtual Machine.
• vm-power: Shows the power state the VM is currently in (running, halted).

* Enable the auto power on feature for the specified VM:

[root@ ~]# xe vm-param-set uuid=[uuid-vm] other-config:auto_poweron=true

 
Which uses the following additional syntax:

• uuid-vm: A unique identifier for the Virtual Machine.

Fuente:

http://www.virtues.it/2011/10/xenserver6-vm-auto-start-feature/

Almacenamiento en Citrix XenServer: cómo funciona y qué puede fallar

El almacenamiento es un aspecto clave en un entorno Citrix Systems Inc. XenServer. Los archivos de imagen de disco de la máquina virtual (VMDK) residen ahí, y si algo falla entonces no es posible arrancar las máquinas virtuales. Por lo tanto, si su centro de datos está ejecutando XenServer y tiene algún poder sobre la administración, debe entender cómo se organiza el almacenamiento.

En un entorno XenServer, los dispositivos de almacenamiento físico están disponibles en un repositorio sobre el que se crea una base de datos que permite a los hosts de XenServer poder conectar con el almacenamiento. Si hay problemas a la hora de reconocer ese almacenamiento, suele deberse a errores de identificación del almacenamiento físico con la identificación de la base de datos de XenServer. Pero antes de explicar cómo poder resolver este problema, hablemos de la relación entre XenServer y el almacenamiento.

En XenServer el almacenamiento se organiza a través de repositorios de almacenamiento, que contienen imágenes de disco virtual, dispositivos de bloque físico y dispositivos de bloque virtual. Y la máquina virtual puede usar el almacenamiento de distintas maneras: como un archivo de disco virtual (creado en el formato de disco duro virtual, o VHD), un gestor de volúmenes lógicos (LVM) o una conexión directa a la SAN a través de Citrix StorageLink.

Si profundizamos en el almacenamiento de XenServer, un repositorio de almacenamiento es una abstracción del dispositivo de disco físico, que pueden ser un dispositivo local o un dispositivo en SAN. En el repositorio de almacenamiento de XenServer, las imágenes de disco virtual se crean como una abstracción del almacenamiento de objetos que pueden ser presentados a una máquina virtual. Para hacerlo, el repositorio de almacenamiento conecta los dispositivos basados en bloques que están ubicados en una máquina local, en SAN o donde sea, usando el objeto de conector de dispositivos de bloque físico de XenServer. Conforme a la imagen de disco virtual, el almacenamiento puede presentarse a la VM. Este almacenamiento se ofrece como objeto de conector de dispositivo de bloque virtual, que la VM ve como su disco virtual.

Como ya hemos indicado antes, hay tres formas para que una VM acceda al almacenamiento. El sistema clásico es mediante archivos VHD. Estos son archivos almacenados en el repositorio de almacenamiento siguiendo el formato estándar definido por Microsoft en 2005. Desde el lanzamiento de XenServer 5.5 en 2009, Citrix también ofrece acceso a través de LVHD o discos duros virtuales basados en LVM. El beneficio de este enfoque es que la capa subyacente de LVM permite aplicar algunas soluciones avanzadas de gestión de almacenamiento como el clonado rápido o las instantáneas. Una tercera opción sería asignar una VM directamente a una LUN en el sistema de almacenamiento. Este sistema solo funciona si su sistema de almacenamiento tiene un complemento que lo soporte.

Un problema frecuente que puede ocurrir en el almacenamiento son los errores en la identificación del almacenamiento. Si esto ocurre se pierde el acceso a todo el almacenamiento. En la plataforma XenServer los dispositivos de disco pueden ser dirigidos de distintas formas por diferentes componentes del sistema. En XenCenter, se refiere al almacenamiento con un identificador de SCSI que corresponde con el UUID que usted puede ver en la consola de XenServer. Si su almacenamiento no es accesible desde XenCenter, compruebe que los UUID usados en XenCenter coinciden con los UUID visibles en la consola XenServer en el directorio /dev/disk/by-uuid.

Si el almacenamiento está basado en LVM, puede encontrar el identificador del almacenamiento del dispositivo de disco a través del comando pvs de la consola de XenServer. Las VM individuales están conectadas a volúmenes lógicos individuales. Para tener una visión general de estos, puede usarse el comando lvs, que muestra de nuevo un identificador que corresponde con el identificador usado en XenCenter.

Si hay un error de configuración en la forma en que se maneja el almacenamiento, entonces usar el comando xe en el host puede ser útil. Este comando le permite ejecutar una consulta directa al host y ver qué dispositivos de almacenamiento «puede ver». El comando necesario es xe sr-list. Este comando muestra los UUID actualmente en uso junto a los demás parámetros que nos permiten identificar el tipo de almacenamiento.

Si usamos xe sr-list, podemos consultar el repositorio de almacenamiento para obtener más información, usando parámetros adicionales. Por ejemplo podemos usar xe sr-list params=name-label,uuid,VDIs,PBDs para ver los diferentes UUID asignados al dispositivo de almacenamiento. El objetivo es encontrar los UUID de los dispositivos reales tal y como se ven en el repositorio de almacenamiento y compararlos con los UUID tal y como se ven en XenCenter. Si hay un error, debe volver a importar los dispositivos de almacenamiento al entorno de administración de XenCenter para reconstruir la base de datos.

Veamos un ejemplo real sobre cómo puede ocurrir esta identificación errónea: una organización de TI con la que trabajo perdió la conexión de todos sus dispositivos de almacenamiento después de migrar sus hosts de XenServer a un nuevo centro de datos. Tras analizar la configuración, resultó que los problemas fueron provocado por un error de los identificadores reales en el almacenamiento y los identificadores tal y como se conocían en la base de datos utilizada por XenServer. Después de encontrar los problemas, la solución fue sencilla: usar el comando xe sr-rescan para escanear de nuevo los identificadores de los dispositivos físicos y volver a construir la base de datos.

Sander van Vugt es formador independiente y consultor residente en Holanda.

Fuente:

http://searchdatacenter.techtarget.com/es/consejo/Almacenamiento-en-Citrix-XenServer-como-funciona-y-que-puede-fallar