Montar img con offset automaticamente. kpartx

En alguna oportunidad, necesitamos montar una imagen de disco (formato qcow) de KVM o de HVM (Xen) para poder acceder a los archivos contenidos allí dentro, pero la cosa no era tarea fácil (calcular el offset del sector de la geometría de la partición, hacer el losetup, etc); la forma más rápida es usando kpartx.

Kpartx es una aplicación cónsola (parte de los multipath-tools por cierto) que permite crear automáticamente los device mappings (dispositivos en /dev) de cualquier dispositivo de bloque.

Instalando kpartx

Aunque lo podemos instalar junto con los multipath-tools, lo podemos instalar de manera independiente:

aptitude install kpartx

Usando kpartx con KVM/HVM

Hemos creado una máquina virtual con KVM/HVM, la misma está en un archivo de imagen ó en un dispositvo LVM, para mapear todas las particiones de dicha imagen KVM como dispositivos de bloque, simplemente ejecutamos:

kpartx -a /dev/mapper/vgVM-maquina1

Siendo /dev/mapper/vgVM-maquina1 el volumen lógico donde está la máquina virtual, si está en un archivo en disco, sería:

kpartx -a /srv/kvm/maquina1/disk1.img

 Read more

Switching to clocksource hyperv_clocksource

Hemos encontrado un problema en la instalación de CentOS / RHEL en XenServer 6.0.

El problema consiste en que, en el arranque, el sistema parece intentar sincronizarse con el reloj del hipervisor:

Switching to clocksource hyperv_clocksource

Sin embargo, una vez que aparece este mensaje no dejan de verse trazas incomprensibles que hacen que el servidor no arranque.
Lo que ocurre es que la máquina virtual va a hacer uso del reloj del hipervisor. Si pudiéramos arrancarlo (y en las máquinas que no se dé este error) veremos:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
xen

Para acabar con el problema es necesario activar HPET.

El HPET no es propiamente una característica del procesador, sino del chipset del motherboard. Este no afectará en nada el rendimiento de tu sistema actual, más bien mejoraría un poco la compatibilidad del mismo ya que es frecuente que algunos kernels modificados lo requieran.

Ya que la máquina no arranca, la configuración consiste en editar el grub.conf (e) y en la línea que carga el kernel añadir un parámetro:
kernel /xen.gz dom0_mem=3118M clocksource=xen

Como nos indican en el artículo siguiente:
http://labs.creativecommons.org/2012/04/10/setting-kernel-clocksource-to-hpet-solves-mysterious-performance-issues/

Incluir este parámetro resuelve problemas misteriosos de funcionamiento.

Cloud computing. Diferencias HVM, PVM y virtualización del sistema operativo

Pues aquí estamos de nuevo con un tema de virtualización, que está muy de moda.

Alcance del documento

La información que encontramos diariamente en las webs especializadas es extensa, por no hablar de la oferta de hosting que se proporciona a nivel de máquinas virtuales, que podría decirse que ha revolucionado el mundo del hardware hasta el punto de que los clientes se planteen la necesidad de adquirir propiamente dicho hardware, o recibirlo como un servicio (HaaS – hardware as a service) que un proveedor se compromete a mantener en determinados niveles de calidad.

Aquí lo que pretendemos hoy es dar un primer enfoque técnico a las diferentes formas de virtualizar, entendiendo su funcionamiento y el porqué de esta pequeña revolución del hardware.

Concepto

La virtualización es la abstracción de los recursos de una computadora (host anfitrión) en una capa lógica llamada hipervisor que, mediante un software, se encarga de gestionar dichos recursos para proporcionárselos eficientemente a las diferentes máquinas huesped (guests) o máquinas virtuales.

Tipos

Si decíamos que la virtualización es la abstracción de los recursos del sistema, tales recursos podrán ser el hardware propiamente dicho (CPU, memoria, disco, tarjetas de red, periféricos), incluyendo o no el software para manejar dichos dispositivos (drivers), o podrán ser recursos software, programas diversos o el propio sistema operativo, que a su vez gestiona el hardware. Y esta es una clasificación típica:

FULL VIRTUALIZED (HVM – Hard Virtual Machine)

Como su nombre indica, se trata de una virtualización completa de la máquina. En este tipo de virtualización, la máquina virtual no es consciente de que realmente es virtual (huésped – guest), esto implica que el sistema operativo y el kernel trabajan de manera  completamente independiente, como si se tratara de una máquina física, sin interactuar con el hypervisor.

Evidentemente que sus recursos hadware (discos, memoria, tarjetas) son físicamente del anfitrión (host). Para que este sistema operativo de HVM los emplee, sus drivers han de ser emulados. Es por esto que debe existir un acoplamiento perfecto entre el host (su microprocesador hardware, su hypervisor software) y el guest (la capacidad de su sistema operativo para correr los recursos proporcionados por el host).

Si un software de hypervisor determinado no está optimizado correctamente para el microprocesador del host, la emulación de los drivers será mala, y la máquina virtual no funcionará bien. Además, es requisito que el microprocesador permita esta configuración a nivel de BIOS, debe permitir AMD/UTX Virtual.

PARAVIRTUALIZED (PVM)

Una máquina paravirtualizada es una máquina que es consciente de que es un máquina virtual, y que para correr requiere que el hypervisor le presente los recursos hardware del anfitrión. Esta comunicación se produce a nivel software de sistema operativo y kernel, no a nivel hardware, por lo que se requiere un buen acoplamiento entre el hypervisor y los distintos sistemas operativos que pueda correr la máquina virtual.

Como se trata de una tecnología en auge, la mayoría de los sistemas operativos importantes, y por descontado Windows y Linux permiten y están optimizados para trabajar con los hypervisores HyperV, XEN, VMWare, RHEV … Esto hace de este tipo de virtualización la óptima para la mayoría de los entornos.

En este caso, los drivers no son emulados, puesto que la máquina virtual ya es consciente de que no tiene conectados físicamente los dispositivos. Se utilizan drivers genéricos optimizados para virtualización, para compartir recursos hardware con el anfitrión. Puede ocurrir que la máquina requiera un driver no genérico, ha de instalarse aparte el driver optimizado para virtualización, de lo contrario no podrá ser empleado ese recurso por el sistema operativo.

VIRTUALIZACIÓN DEL SISTEMA OPERATIVO

El software del sistema operativo y sobre todo su núcleo (kernel) son los encargados de interpretar y traducir las órdenes de las aplicaciones y al final, usuarios del sistema, con el hardware, gestionando y administrando la utilización de los recursos del hardware disponible.

Cabe por lo tanto preguntarse ¿por qué no virtualizar también el sistema operativo? Es decir, que no sea necesario instalarlo a posteriori tampoco en las máquinas virtuales, que lo comparta con el host anfitrión. La respuesta es que efectivamente esta virtualización favorece la gestión, el rendimiento y la eficiencia de las máquinas virtuales, con el correspondiente ahorro de disco. Hay software de virtualización especializado en este tipo.

Como contrapartida, no podremos lógicamente y por concepto, tener otros sistemas operativos en las máquinas virtuales.

Espero haber dejado claros algunos puntos acerca de la virtualización.

Recursos monitorización XEN

En continuación con el post anterior, en el que aparecían diversas formas de monitorizar un servidor de virtualización XEN, la comunidad ha ido desarrollando diversos plugins y templates que ya permiten integrar scripts similares.

Concretamente, la template que podemos añadir a ZABBIX se encuentra en:

http://www.aceslash.net/misc/fms_xen_dom0.xml

 

Y el nagios-plugin cuyas posibilidades podemos explorar se encuentra en:

http://www.monitoringexchange.org/in…inux/check_xen

 

Cualquier comentario en cuanto a cómo usarlos o su funcionamiento, es bienvenido.

Monitorización de sistemas XEN con Nagios o ZABBIX

Más de uno nos hemos preguntado cómo monitorizar sistemas de virtualización basados en tecnología XEN con Nagios o ZABBIX.

Aquí os dejo una documentación que incluye unos scripts que nos pueden servir de base para realizar tareas de monitorización para sistemas centralizados:

To do and read before you begin

  • Almost everything is based on “xentop -i -b”, but be caution, the output of this command can change depending on your server OS (redhat/centos or debian). In particular, the number of line before domain data can change, so you may to adjust the first sed to have what you want. Bellow are the settings for Xen 3 on RHEL/CentOS/SELinux 5.x.

Read more