Entre ruedas y alas

Error VDI (FAILURE 46) al arrancar nuestra VM

Tras un reinicio del HOST nos encontramos con alguna VM que no consigue arrancar. Al realizar el Start de la misma, aparece un error en la pestaña de Logs que indica que el VDI de la VM no esta disponible.

Este es un error conocido, que tiene fácil solución. Por desgracia el log de la pestaña de XenCenter no da mucha información útil, así que mi recomendación es ir siempre al CLI y ejecutar desde allí el comando.

xe vm-start uuid=UUID_VM

dando como resultado:

Error code: SR_BACKEND_FAILURE_46

Error parameters: , The VDI is not available [opterr=Error scanning VDI UUID=XXXXX]

Por alguna razón el VDI de la VM en cuestión no esta disponible. La solución es muy sencilla:

Primero de todo, vamos a localizar el disco de la VM afectada, para ello ejecutaremos:

xe vdi-list name-label=NOMBRE\ VM\ AFECTADA

Esto nos mostrará el uuid de los VDI que tiene asignada la VM en cuestión. Es importante también localizar en que SR esta dicho disco.

Tras ello, vamos a quitar dicho disco “fantasma” de la VM dónde se encuentra asignado, para ello ejecutaremos:

xe vdi-forget uuid=UUID\ VM\ COMANDO_ANTERIOR

Ello, quitará el disco con UUID de la VM asignada. Tras ello, realizaremos un Re-scan de los SR. Podemos realizar-lo desde la consola XenCenter o desde la CLI.

xe sr-scan

Una vez finalizado el proceso, incluimos de nuevo el disco sobre la VM. Desde XenCenter con la opción de atach y seleccionando el correspondiente disco de la VM (tengo la costumbre de dar nomenclatura especifica a cada disco aprovisionado para que sea mas fácil su localización por nombre, no es una mala practica 😉 )

También podéis realizar-lo desde cli, por supuesto 😉

Una vez finalizado, simplemente, arrancad la VM.

Falta de Swap en Virtual Appliance Zabbix

Zabbix es una herramienta de monitorización estupenda, con una curva de aprendizaje amplia, pero una herramienta con mucho recorrido.

En las últimas versiones de esta genial herramienta, podemos realizar tanto la instalación y descarga de la misma en formato virtual appliance, con lo cual, en la mayoría de los entornos, facilitará nuestra implementación y será mas que suficiente.

Un problema que me encuentro en TODAS las implementaciones basadas en este virtual appliance, es el siguiente error:

Lack of free Swap space on Zabbix Server

Ello es debido a que el virtual appliance distribuido no lleva reserva de disco para la memoria swap.

Vamos a ver un paso a paso, para la solución del problema.

1. Conectamos y nos validamos en la shell de nuestro v.apliance (local o vía ssh).

2. Ejecutamos lo siguiente:

# free -tom : Nos muestra la memoria disponible, utilizada y libre. Veremos que no disponemos de swap.

# swapon -s : nos muestra las estadísticas de nuestro swap. Debería aparecer a 0.

Ahora vamos a crear nuestra unidad swap.

# dd if=/dev/zero of=/var/swap_1 bs=1024 count=1000000 : Con esto generamos el fichero swap_1 de 1GB de espació que utilizaremos como swap.

# mkswap /var/swap_1 : Especifica /var/swap_1 como área swap de nuestro sistema.

# swapon /var/swap_1: Habilita swap sobre el fichero especial.

Con esto ya tendríamos solucionado el problema temporalmente. Vayamos a indicar-le a fstab que este sea montado/utilizado en el inicio del sistema.

# vi /etc/fstab : Editamos el fichero fstab

Añadir la siguiente linea:

/var/swap_1 swap swap defaults 0 0

Tras ello podemos reiniciar la máquina y verificar que este aparece correctamente. Para ello:

# free -tom : Nos muestra la memoria disponible, utilizada y libre. Veremos que no disponemos de swap.

# swapon -s : nos muestra las estadísticas de nuestro swap.

Y con esto, ya tenemos nuestro problema de swapfile solucionado en nuestro virtual appliance de Zabbix, basado en OpenSuse.

Generando un default profile centralizado. (2008S & 2012S)

Generando un perfil por defecto centralizado

Existen muchos casos en los cuales los perfiles de usuarios deben ser, no solo optimizados, si no customizados por necesidades de los mismos.

Estas modificaciones o customizaciones del mismo, pueden incluir, desde iconos específicos por defecto en el escritorio de usuario, modificaciones sobre la moneda y/o el sistema decimal i/o otras modificaciones no realizables o que no vale la pena incluir en modificaciones por GPOs.

Disponer de un perfil default customizado, posibilita que cualquier nuevo usuario en el entorno, disponga de un esqueleto del mismo, de forma predeterminada, evitando tener que modificar el mismo una vez generado por parte del usuario. De este modo, cualquier modificación que deba afectar a todos los usuarios, será incluido en este perfil.

Generando el esqueleto por defecto.

Lo primero que debemos saber es que debe incluir o que modificaciones deben ser comunes para todo el global de los usuarios de nuestro entorno. Es importante saber de antemano que es necesario, pues nos evitará tener que ir modificación/regenerando el perfil por defecto una y otra vez.

Una vez sepamos que cambios deben ser aplicados de antemano sobre el perfil de usuario, procederemos a la generación del mismo, siguiendo los pasos definidos a continuación:

Cabe tener en cuenta que :

El único método admitido para la personalización del perfil de usuario predeterminado es mediante el parámetro Microsoft-Windows-Shell-Setup\CopyProfile que se encuentra en el archivo de respuesta Unattend.xml. El archivo de respuesta Unattend.xml se transfiere al la Herramienta de preparación del sistema (Sysprep.exe).

Procedimiento:

Iniciar sesión como Administrador local o un usuarios con derechos de administrador ocal. Es importante tener en cuenta que no es posible realizar este proceso con una cuenta de administrador de dominio.

A grandes rasgos, en este punto, debemos realizar todas las modificaciones sobre el perfil, que queramos que sean incluidas en el defaultprofile.

Tras ello, procederemos a generar el fichero de creación unattended.xml.

Vamos a ver el procedimiento por pasos.

– Nos logamos como administrador local

– Realizamos los cambios específicos sobre el perfil.

– Creamos el fichero unattend en C:\windows\system32\sysprep\

– Este fichero debe incluir como mínimo la opción Microsoft-Windows-Shell-Setup\CopyProfile en True.

– Establecer la opción “CopyProfile” a “True”

– Ejecutar: sysprep /generalize /oobe /unattend:unattend.xml

Como generamos el fichero unattend.xml

Utilizaremos para ello Windows SIM (incluido en el AIK Y/o ADK) el cual nos permitirá generar el fichero unattend a través de una GUI.

Una vez descargado e instalado en nuestra maquina, generamos el fichero unattend.xml como mínimo, con la opción de CopyProfile, utilizando para ello Windows SIM.

Utilizando Windows SIM

Instalado nuestro SIM desde AEK o desde AIK (segundo el SO utilizado), procedemos a la generación de nuestro unattend.xml.

Abrimos Windows SIM y creamos un nuevo fichero de respuesta.

Para modificar el archivo de respuesta, necesitaremos disponer de una imagen de Windows. Para ello, copiaremos en un recurso local la ruta “Sources” del CD de instalación. En ella se incluyen los ficheros de Windows Image necesarios.

Especificamos imagen .win a utilizar y generamos el catalogo .clg.

En este punto, vamos a incluir la opción de copia de perfil. Expandimos “Components” y buscamos amd64_Microsoft-Windows-Shell-Setup.

Agregamos el componente en la sección 4_Specialize:

En el archivo de respuesta seleccionar: Components\4_specialize\amd64-Microsoft-Windows-Shell-Setup_neutral.

Aquí en la sección de Propiedades establecemos el valor copyProfile a TRUE.

Guardamos el archivo de respuesta como “CopyProfile.xml”

Tras ello, ejecutamos el comando indicado en el procedimiento: sysprep /generalize /unattend:unattend.xml

C:&gt; Sysprep /generalize /oobe /shutdown /unattend: C:\File.xml

1	C:> Sysprep /generalize /oobe /shutdown /unattend: C:\File.xml

Tras generalizar la imagen, se apagara el equipo. Esta nueva imagen incluirá el default profile modificado. podemos desplegar desde esta imagen Windows con las configuración especifica del perfil customizado.

Levantada esta imagen, es momento de copiar el default profile en un recurso de red, para utilizar de forma centralizada.

Notas:

– Si queréis comprobar el log, no utilizar la opción /shutdown en el proceso de sysprep. Podreis encontrar el log en: %systemroot%\panther\unattendgc\setupact.log

– Debe utilizar el modificador /generalize con sysprep.exe para que se pueda usar el parámetro Copy Profile. La opción /unattend se utiliza para seleccionar el archivo Unattend.xml

– El perfil de la cuenta predefinida de administrador se elimina cuando se realiza una instalación de Windows limpia o cuando se ejecuta la herramienta Sysprep. El parámetro CopyProfile se procesa antes de que la cuenta predefinida de administrador se elimine. Por lo tanto, cualquier personalización que realice, aparecerá en el nuevo perfil de cuenta de usuario. Esto incluye la configuración de perfil de cuenta predefinida de administrador.

– Si hay varios perfiles de usuario, puede que la utilidad sysprep de Windows elija un perfil no esperado y lo copie en el perfil de usuario predeterminado. Por ello se recomienda eliminar todos los perfiles del sistema y dejar únicamente el perfil de administrador a modificar.

– No todas las personalizaciones se propagarán a los nuevos perfiles. El proceso de inicio de sesión del nuevo usuario reestablecerá algunas de las opciones. Para configurar los valores de configuración, utilice la configuración de directiva de grupo o el scripting.

Generando el punto compartido para el Default Profile

Veamos como copiar y definir este perfil de forma centralizada. Para ello, deberemos conectarnos al recurso:

\\DomainServer\NETLOGON

Dentro, creamos una carpeta que utilizaremos como default profile, por ejemplo:

Default Profile.V2

Situarnos en Equipo > Propiedades > Configuración Avanzada del sistema

Tras ello, seleccionar el Default Profile y clicar en la opción “Copy to”

Seleccionamos la nueva ubicación del perfil. En nuestro caso, el recurso de red:

\\DomainServer\NETLOGON\Default Profile.V2\

Seleccionamos “Cambiar” > “todos” > Aceptar.

Una vez realizado, ya podemos utilizar las GPOs de AD para configurar el recurso por defecto para almacenar el perfil default del entorno.

Recursos:

Personalizar el perfil de usuario local predeterminado al preparar una imagen de Windows: http://support.microsoft.com/kb/973289

Utilizar Windows SIM: http://technet.microsoft.com/es-es/library/dd799285%28v=ws.10%29.aspx

Descargar AIK Windows 7 y 2008R2: http://www.microsoft.com/es-es/download/details.aspx?id=5753

Y/O Windows ADK para Windows 8 / 2012 Server: http://www.microsoft.com/es-es/download/details.aspx?id=39982

Tunning Dom0 en XenServer (memoria y vcpus)

XenServer permite el “tunning” del Dom0 de cara a mejorar la escalabilidad del entorno cuando es necesario, poniendo de este modo el rendimiento de nuestro hypervisor al máximo.

Cabe indicar, que no siempre estas recomendaciones son aplicables y que habrá que ver cada entorno, para saber si es o no es aplicable. De echo, normalmente estas recomendaciones no serán aplicables ya que la configuración por defecto de XenServer es en la mayoría de casos suficiente.

Pero si tenéis problemas de rendimiento a pesar de tener suficiente CPU y memoria, ello puede estar ocasionado por un cuello de botella es nuestro dominio de control y los siguientes ajustes podrían solventar en algunos casos dicha perdida de rendimiento.

Cuando un host XenServer arranca, el hypervisor carga una pequeña VM invisible para los usuarios; incluso para los administradores en algunos casos. Esta VM es conocida como Dominio de Control o Dom0. Dom0 se ejecuta en la pila de gestión y proporciona servicios básicos al resto de las VMs, como el acceso físico a los dispositivos.

No existe un número determinado de VMs en las cuales podamos asegurar que la vcpu0 de dom0 se colapse, ocasionando un cuello de botella. Dependerá también en gran medida del tipo de VMs que estemos rodando, pudiendo ser necesario realizar cambios en dom0 a partir de 60-70 vms o no siendo necesario realizar incluso con 100 vms rodando. Por ello, es importante no tener una referencia numérica en este aspecto, y revisar los contadores y el estado de nuestro Dom0 para asegurar un correcto tunning. En el 99% de los casos, no serán necesarias modificaciones en Dom0.

Si durante el uso de nuestro host, observamos problemas de rendimiento, y mediante xentop comprobamos un uso excesivo (llegando al 100% constante) de recursos, se recomienda, en estos casos, el tuning de dom0, ampliando memoria o asignando vcpus, según corresponda.

Ya hemos hablado de ampliar el número de vcpus de nuestro dominio de control, pero también la memoria se puede ver afectada en estos problemas de cuello de botella. Sobretodo en entornos con mas de 50 Vms corriendo por host. En estos, se recomienda la ampliación de memoria hasta 2’96GiB, y decimos 2’96GB y no 4 ya que mas de 2’96GiB queda fuera de soporte, además de ser arriesgado.

Si quieres saber mas, continua leyendo aquí

Install Python 3 on XenServer 6.2

Veamos la versión actual de python en XS6.2

[root@xenserver62 ~]# python -V

Python 2.4.3

Vamos a utilizar YUM en primer momento, para instalar todos los paquetes necesarios para la instalación de Python3.

NOTA: Si al realizar un yum update aparece un error referente al repositorio de Citrix 6.2

* Deshabilitar el repositorio Citrix.Repo

* Habilitar el repositorio CentOS-base Repo

Sobre esto hable hace tiempo en el siguiente link: http://blogs.itpro.es/cristiansan/2012/05/23/xenserver-trick-linux-repository/

Instalando Requerimientos

Habilitados los repositorios. Procedemos a instalar Make y el compilador GCC.

Install Make.

# sudo yum install make

Install GCC

# sudo yum install gcc

Descargamos e instalamos Python3

Para ello, desde nuestra linea de comandos, ejecutamos:

wget http://www.python.org/ftp/python/3.3.2/Python-3.3.2.tgz

tar xf Python-3.3.2.tgz

cd Python-3.3.2/

./configure –prefix=/usr/local

make && make altinstall

ahora ya podemos ejecutar python3.3 sin problemas.

[root@xenserver62 bin]# python3.3
Python 3.3.2 (default, Jul 10 2013, 16:22:51)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux
Type «help», «copyright», «credits» or «license» for more information.
>>>

NOTA: Si ejecutamos python seguimos en versión 2.4.3

NOTA: No se recomienda el cambio del link symbolico, pues muchos programas realizados en Python apuntan a «python» como enlace de Python2. Modificar-lo puede suponer un problema para scripts que necesiten de python2.

TRICK: Para simpliciar las cosas, podemos crear un link simbólico “py” para ejecutar python3.

# ln /usr/local/bin/python3.3 /usr/bin/py

De este modo, al ejecutar py, estaremos ejecutando python 3.3

[root@xenserver62 bin]# py -V
Python 3.3.2
[root@xenserver62 bin]# py
Python 3.3.2 (default, Jul 10 2013, 16:22:51)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux
Type «help», «copyright», «credits» or «license» for more information.
>>>

Y con esto, y un biscocho, ya tenemos Python 3 en nuestro querido XenServer 6.2. 😉

Estados-C y Citrix XenServer

C-State

Cuando una maquina esta inactiva, con el fin de ahorrar energía, es posible hacer que la cpu entre en modo bajo consumo. Cada cpu tiene varios modos y son llamados de forma colectiva estados C (C-State).

El trabajo de estos modos, es cortar el reloj de las unidades inactivas dentro de la CPU. Cuantas mas unidades se paran, mas ahorro de energía se obtiene, pero se requiere de mas tiempo cuando es necesario “despertar” las VMs para disponer de nuevo el sistema 100% operativo.

¿Problemas en virtualización?

Los estados-C pueden (en algunos casos) suponer un problema en entornos virtuales, ocasionando picos de memoria/cpu o cortes intermitentes de red. El uso del modo Turbo y de los estados C, suele ser el responsable de estos problemas.

Si se encuentra con problemas debido a ello, puede des-habilitar esta funcionalidad.

¿Están los C-State habilitados?

Podemos ver y configurar esta funcionalidad desde la Bios de nuestro servidor. Ello ocasiona que para realizar la comprobación paremos maquinas y reiniciemos el host. Existe, pero, un método para verificar este estado sin necesidad de entrar en la Bios y reiniciar el host.

Verificar C-State en XenServer.

Para ello, abriremos una sesión SSH con nuestros host (mediante putty o a través de XenCenter) y teclearemos:

xenpm get-cpuidle-states | grep total | uniq

• Si Total C-States = 4 ; los C-States están habilitados
• Si Total C-States = 2; Los C-States no están habilitados.

Extra Info:
How to Disable C-States and Turbo Mode on Fujitsu Servers : http://support.citrix.com/article/CTX136863
Hosts Become Unresponsive with XenServer 5.6 on Nehalem and Westmere CPUs: http://support.citrix.com/article/CTX127395