Monthly Archives: November 2011

Cambiar la imagen ISO del CDROM en una máquina virtual con virsh

Introducción

Manejando máquinas virtuales GNU/Linux basadas en KVM utilizo Libvirt como capa adicional para su gestión.  Esto provee herramientas prácticas para su administración local y remota como virsh (consola) y virt-manager (GUI).

Instalando la versión 5.6 de Scientific Linux me encontré con una situación que venía evitando resolver desde hacía unos días: para finalizar la instalación era necesario cambiar el "cdrom" de la máquina virtual del ISO del primer DVD de la distribución al segundo.

Para hacer esto remotamente utilicé virsh y el comando descrito a continuación.

Conexión remota a la consola de administración

El primer paso por supuesto, si es que no se ha hecho aún, es realizar la conexión remota a través de SSH a la consola de administración de las máquinas virutales.  Esto se logra mediante la ejecución del siguiente comando.

$ virsh –connect qemu+ssh://servidor/system

Modificar el "cdrom" de la máquina virtual

Una vez en la consola de administración, para hacer esto sólo es necesario ejecutar la siguiente instrucción.

virsh # attach-disk –type cdrom –mode readonly scientificlinux_56_x86-64_generic /b1/ISO/SL.56.061711.DVD.x86_64.disc2.iso hdc

En este caso se está "montando" la imagen ISO contenida en el archivo /b1/ISO/SL.56.061711.DVD.x86_64.disc2.iso como primer CDROM de la máquina virtual scientificlinux_56_x86-64_generic.

Configurar una interfaz de red en puente (bridge) en ArchLinux

Introducción

En este procedimiento se establecen los pasos necesarios para configurar una interfaz de red (br0) en puente con la interfaz de la red alámbrica (eth0) para permitir el acceso directo a la red LAN de las máquinas virtualizadas con KVM instalado previamente.

Para este montaje se utilizó ArchLinux en su versión mas reciente, la 2011.08.19, en la cual se observaron algunos cambios en los archivos de configuración, especialmente en los relacionados con la configuración de redes lo cual impacta directamente con lo descrito a continuación.  Para versiones anteriores del sistema operativo se ofrece una alternativa de configuración que no ha sido probada en producción.

Instalar los paquetes necesarios

Para la configuración de múltiples interfaces de red.

$ sudo pacman -S netcfg

Para la creación del puente entre las interfaces de red.

$ sudo pacman -S bridge-utils

Desactivar la configuración original de red

En esta versión de ArchLinux la configuración de una interfaz de red se realiza de manera diferente a múltiples interfaces de red.  En este caso partimos de una única interfaz de red (eth0) a tener dos (eth0 + br0), por este motivo es necesario desactivar la configuración actual para implementar la otra aproximación.

Comentar las líneas relacionadas con la configuración de la interfaz de red actual.

$ sudo vi /etc/rc.conf

## interface=eth0
## address=192.168.1.250
## netmask=255.255.255.0
## broadcast=192.168.1.255
## gateway=192.168.1.254

Remover la invocación de network de la variable DAEMONS.

Configurar las múltiples interfaces de red

En este paso se deberá configurar la interfaz de red removida en el paso anterior junto con la interfaz correspondiente al puente a crearse con ella.

$ sudo vi /etc/rc.conf

  1. Agregar la invocación de net-profiles en la variable DAEMONS.
  2. Agregar la referencia de las nuevas interfaces en la variable NETWORKSde la siguiente manera.

    NETWORKS=(eth0 br0)

Crear la especificación de la configuración de las nuevas interfaces bajo /etc/network.d.  Para mayor información al respecto consultar los ejemplos ubicados en /etc/network.d/examples.

$ sudo vi /etc/network.d/eth0

INTERFACE="eth0"
CONNECTION="ethernet"
DESCRIPTION="Wired network interface"
IP='static'

$ sudo vi /etc/network.d/br0

INTERFACE="br0"
CONNECTION="bridge"
DESCRIPTION="KVM Bridge connection"
BRIDGE_INTERFACES="eth0"
POST_UP='brctl setfd br0 0'
IP='static'
ADDR='192.168.1.250'
GATEWAY='192.168.1.254'
DNS=('8.8.8.8', '8.8.4.4')

Versiones anteriores

 Otra aproximación a la implementación de esta solución que aparentemente era útil en versiones anteriores del sistema operativo consiste en realizar los ajustes necesarios al archivo /etc/conf.d/bridges de la siguiente manera.

$ sudo vi /etc/conf.d/bridges

bridge_br0="eth0"
config_br0="brctl setfd br0 0"
BRIDGE_INTERFACES=(br0)

Finalmente se actualiza el archivo /etc/rc.conf para incluir a br0 como una nueva interfaz de red.

$ sudo vi /etc/rc.conf

eth0="eth0 up"
br0="br0 192.168.1.250 netmask 255.255.255.0 up"
INTERFACES=(lo eth0 br0)

Enlaces

Actualización de Scientific Linux 5.x a la versión 6.x

Introducción

Los servidores del Cluster que coordino utilizan Scientific Linux 5.4 debido a que en el momento es la mejor distribución basada en RedHat que existe además de ser completamente compatible con Condor y el software de OpenScienceGrid el cual es nuestro objetivo primario actualmente.

Intentando prever el futuro he estado haciendo pruebas de actualización del este sistema operativo a su versión mas reciente (6.1) en máquinas virtuales a pesar de que el software de OSG aún no cuenta con el soporte adecuado.

A continuación se relaciona el procedimiento de actualización que he venido realizando durante las pruebas.

Procedimiento de actualización

Hacer la correspondiente copia de seguridad.

Actualizar los paquetes disponibles para la versión actual.

# yum update

Limpiar los paquetes y cabeceras descargadas previamente.

# yum clean all

Verificar que se cuente con suficiente espacio para la descarga, descompresión e instalación de los nuevos paquetes, especialmente bajo /var/cache.

Actualizar la versión del sistema (sl-release).  Ajustar la versión objetivo según la deseada.

# yum –releasever=6.1 update sl-release

Actualizar los paquetes para la nueva versión del sistema operativo.

# yum update

Verificar que el GRUB se haya actualizado correctamente.

Limpiar los paquetes y cabeceras descargadas previamente para liberar espacio (opcional).

# yum clean all

Reiniciar el sistema operativo para que los cambios producto de la actualización sean tenidos en cuenta.

Enlaces

Instalando libvirt en ArchLinux

Introducción

Libvirt es un API de código abierto y una herramienta de administración para diferentes sistemas de virtualización entre los que se encuentran Xen, OpenVZ, Virtualbox, VMWare, Microsoft Hyper-V y por supuesto KVM/Qemu instalado en el servidor de desarrollo previamente.

Este software es ideal para la gestión de las máquinas virtuales y su administración remota a través de conexiones seguras con SSH.  Además incluye una librería en C para el desarrollo de aplicaciones e incluye además interfaces para diversos lenguajes como Python, Perl, Ruby, Java y PHP.

Instalación del software

Instalar los paquetes del repositorio oficial.

# pacman -S libvirt urlgrabber dnsmasq bridge-utils

Inicio automático del demonio

Configurar el demonio de libvirtd para que se inicie automáticamente junto con el sistema operativo.

# vi /etc/rc.conf

DAEMONS = (… libvirtd …)

Debe tenerse en cuenta que el demonio libvirtd requiere ser invocado después de dbus y avahi-daemon.

Autorizar la administración a usuarios sin privilegios

Si se desea que usuarios sin privilegios (diferentes de root) administren las máquinas virtuales, estos deberán ser explícitamente autorizados de la siguiente manera.

# vi /etc/polkit-1/localauthority/50-local.d/org.libvirt.unix.manage.pkla

[Allow a user to manage virtual machines]
Identity=unix-user:jimezam
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Si en lugar de administración se desea conceder la autorización para monitorear las máquinas se deberá especificar la siguiente acción.

org.libvirt.unix.monitor

Permitir el acceso a través de SSH

Para permitir el acceso a las máquinas virtuales a través de herramientas como virsh o virt-viewer a través del protocolo SSH (qemu+ssh) es necesario contar con paquete netcat de OpenBSD instalado de la siguiente manera.

$ sudo pacman -S openbsd-netcat

Si se cuenta adicionalmente con el paquete netcat convencional instalado es posible que este se haya apoderado del enlace /usr/bin/nc y libvirt intente utilizarlo erróneamente generando el siguiente mensaje de error.

error: server closed connection: nc: invalid option — 'U'
Try `nc –help' for more information.
error: failed to connect to the hypervisor

En ese caso es necesario indicarle a libvirt cual es la versión de netcat que debe utilizar.  Esto se puede realizar desde los parámetros extra del URI en cada invocación de acceso de la siguiente manera.

$ virsh -d 0 –connect qemu+ssh://usuario@servidor/system?netcat=/usr/bin/nc.openbsd

O de manera permanente modificando en el servidor el enlace /usr/bin/nc de la siguiente manera.

$ sudo mv /usr/bin/nc /usr/bin/nc.orig

$ sudo ln -s /usr/bin/nc.openbsd /usr/bin/nc

Enlaces

Instalando KVM en ArchLinux

Introducción

Por fin he destinado el tiempo necesario para reintalar mi servido de desarrollo, esta vez utilizando ArchLinux.  Había utilizado con éxito esta distribución en un par de ocasiones sin embargo no había tenido la oportunidad de explorarla con mayor profundidad.

A continuación se describen los pasos que se siguieron para instalar KVM en ArchLinux.

Verificaciones preliminares

Se requiere de un versión de kernel igual o superior a la 2.6.22.

# uname -a

Linux ivy.jorgeivanmeza.com 3.1.1-1-ARCH #1 SMP PREEMPT Fri Nov 11 22:28:29 CET 2011 x86_64 AMD Phenom(tm) 9650 Quad-Core Processor AuthenticAMD GNU/Linux

De igual manera se requiere que el procesador cuente con soporte físico para virtualización: VMX (Intel) o SVM (AMD).

# grep -E "(vmx|svm)" –color=always /proc/cpuinfo

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs npt lbrv svm_lock

Instalación del software

Instalar los paquetes del repositorio oficial.

# pacman -S qemu-kvm

Agregar las cuentas de los usuarios que utilizarán el software al grupo kvm para que puedan acceder a /dev/kvm.

# gpasswd -a jimezam kvm

Verificar la carga de los módulos de kernel dependiendo del proveedor del procesador.

Para IntelPara AMD

# modprobe kvm

# modprobe kvm-intel

# modprobe kvm

# modprobe kvm-amd

Una vez cargados deberán aparecer en el listado de módulos activos.

# modprobe -l 'kvm*'

kernel/arch/x86/kvm/kvm-amd.ko.gz
kernel/arch/x86/kvm/kvm.ko.gz

En caso de fallar la carga pero haber pasado la verificación inicial, verificar en la configuración de la BIOS si las extensiones de virtualización se encuentran desactivadas.

Configurar la carga automática de los módulos del kernel.

# vi /etc/rc.conf

MODULES=(kvm kvm-amd)

Enlaces

Instalar un kernel sin soporte para Xen en Scientific Linux 5.x

Introducción

Dos de los servidores del cluster estaban presentando problemas con procesos muertos relacionados con tareas en el cron que intentaban acceder a /sys/hypervisor/uuid.  Al parecer el bug 225203 impide que se acceda a este recurso si el servicio de XenStored no se está ejecutando.

awk -v progname=/etc/cron.hourly/mcelog.cron progname {?????   print
> progname ":\n"?????   progname="";????       }????
/bin/bash /usr/bin/run-parts /etc/cron.hourly
cat /sys/hypervisor/uuid

Como el soporte de Xen no era requerido en estos servidores decidí removerlo.  Para hacer esto reemplacé el kernel de cada uno de estos equipos con el correspondiente kernel convencional.  Este procedimiento fue realizado utilizando Scientific Linux 5.4, sin embargo debe ser compatible con otros descendientes de RedHat como CentOS.

Procedimiento

Descargar e instalar los paquetes del nuevo kernel sin soporte para Xen.

# yum install kernel kernel-devel kernel-headers

Remover el kernel actual que cuenta con soporte para Xen.

# yum remove xen kernel-xen kernel-xen-devel

Reiniciar el servidor para que sea tomado en cuenta el nuevo kernel.

# reboot

Problemas para cargar el tema activo en GNU/Linux Mint 11

Introducción

Mint es una distribución muy interesante de GNU/Linux que se encuentra actualmente basada en Ubuntu (también mantienen una basada en Debian).  Entre sus puntos a favor encuentro que incluye por defecto muchos de los paquetes que habitualmente se instalan manualmente en los escritorios Ubuntu, incluye un tema y aplicaciones mejoradas, e incluye todavía la versión 2 de GNOME la cual es mi favorita.  Al respecto de esta última característica, según he leído la versión 12 traerá por defecto GNOME3.

El problema

Con esta última versión he tenido algunos problemas esporádicos con la carga del tema de GNOME el cual en muy pocas ocasiones falla dejando por defecto el tema básico de GNOME.  Con cerrar la sesión del usuario y volver a ingresar con el mismo habitualmente se corrige -temporalmente- este problema.

La situación

En esta versión específica de Mint se presenta un problema de coordinación de tiempos (race condition) entre la ejecución de GDM y los llamados de la sesión a gnome-settings-daemon.  Esto produce que cuando el orden de estos llamos se realiza  de manera incorrecta, la carga del tema del escritorio falle y deba utilizarse el tema por defecto.

La solución

Para solucionar este problema es necesario modificar el archivo de configuración de gnome-settings-daemon y agregar en él un retraso para garantizar el correcto orden en la carga de los servicios.

$ sudo vi /etc/xdg/autostart/gnome-settings-daemon.desktop

Reemplazar la primera linea con la segunda.

## Exec=/usr/lib/gnome-settings-daemon/gnome-settings-daemon
Exec=bash -c "sleep 20; /usr/lib/gnome-settings-daemon/gnome-settings-daemon

Debe adaptar la longitud del retardo (20 según lo propuesto) de acuerdo al contexto específico de su hardware.  Este valor deberá aumentar de manera inversamente proporcional a la velocidad de procesamiento.

Enlaces