VirtualBox y USB
Los usuarios de Ubuntu que instalen VirtualBox en sus sistemas seguramente tendrán problemas para utilizar los dispositivos USB dentro de sus máquinas virtuales. El motivo es que para que dicho software de virtualización pueda acceder a los USB es necesario que el usuario que ejecute la máquina virtual perteneza al grupo vboxusers, algo que no se hace automáticamente. Por suerte, solucionarlo es simple, basta sólo con agregar el usuario al grupo mencionado:
sudo usermod -a -G vboxusers usuario
Luego, con cerrar la sesión y volver a iniciarla ya debería ser posible utilizar los dispositivos USB desde dentro de la máquina virtual.
Virtualización de desktops en Fedora 14
La próxima versión de Fedora, bautizada como Laughlin y que será lanzada el día 2 de noviembre de este año, incorporará la capacidad de virtualizar desktops (entre varias características más), una nueva tendencia en el mundo de la virtualización que puede llegar a resultar realmente interesante, al menos así se presenta.
Dicha capacidad será posible por la incorporación de SPICE (Simple Protocol for Independent Computing Environments), la infraestructura de escritorios virtuales de Red Hat. Será muy lindo ver esto funcionando en un producto OpenSource, sobre todo para hacer frente a otros productos como VMWare que ya tienen versiones orientadas a este área.
Xen Server 5.6 no bootea
En el día de hoy realicé la instalación de un Xen Server 5.6 sobre un disco SATA y, luego de que la misma finalizara con éxito, me encontré con que el sistema no booteaba, tirando los mensajes que se ven a continuación.
Setting hostname myserver: OK INFO: task nash:5244 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
La solución a esto se puede ver en el foro de Citrix y consiste en reemplazar la línea que se muestra a configuración en el archivo /etc/rc.d/rc.sysinit:
[ -x /sbin/nash ] && echo "raidautorun /dev/md0" | nash --quiet
Por esta otra:
/sbin/mdadm -A /dev/md0 <dispositivo 1> <dispositivo 2>
En mi caso no agregué la última línea sino que sólo comente la primera debido a que no tengo ningún RAID en mi sistema (por ahora). Lo que se debe tener en cuenta es que la línea que se está reemplazando autodetecta el RAID y la segunda lo configura manualmente. El problema que puede generar esto es que si por algún motivo se invierte el orden de los discos el RAID se degradaría.
Proxmox: instalación, clustering y migración en vivo
En este post explicaré cómo instalar Proxmox con un particionamiento personalizado y cómo luego formar un cluster con otro equipo con Proxmox. Finalmente, daré una pauta de cómo lograr hacer la migración en vivo de máquinas virtuales.
En mi caso, cuento con dos servidores que soportan virtualización por hardware y he decidido utilizar Proxmox como plataforma de virtualización por varios motivos:
- Es software libre.
- Es gratis.
- Permite virtualizar con KVM y OpenVZ.
- Tiene una interfaz web muy sencilla de utilizar
- Basado en Debian: se lo puede administrar por SSH e instalar cualquier paquete compilado para Debian.
- Soporta varias funcionalidades avanzadas sin adquirir ninguna licencia adicional:
- Migración en vivo.
- Clustering de servidores.
- Backups automáticos de las VMs.
- Posibilidad de conectar a un NAS/SAN con NFS, iSCSI.
Instalación
La instalación de Proxmox es sumamente sencilla dado que se realiza en pocos pasos mediante una interfaz gráfica muy intuitiva. No obstante, cabe destacar que por defecto no se pregunta nada del esquema de particionamiento que utilizará. Desde mi punto de vista, la forma en que se particiona por defecto resulta muy ineficiente, dado que se asigna mucho espacio al directorio raíz y a la swap, espacio que normalmente no se utiliza.
No obstante, como el particionamiento se lleva a cabo utilizando LVM, es posible luego redimensionar esas particiones; sin embargo, es más sencillo escoger el tamaño al momento de la instalación para luego no tener que hacer ningún cambio. Para ello, cuando Proxmox bootea desde el CD la primera vez se queda esperando con un prompt que nos permite pasarle algún parámetro. En este caso, le indicaremos que deseamos un disco raíz de 20GB y una swap de 4GB, de la siguiente manera:
boot: linux maxroot=20 swapsize=4
Una vez finalizado lo anterior se prosigue la instalación guiada normalmente.
Armar el cluster
Contar con un cluster de servidores Proxmox es sumamente útil dado que posibilita migrar máquinas virtuales entre cualquier servidor del cluster y permite administrar todos los servidores Proxmox desde una única interfaz, ubicada en el master.
Por fortuna, crear el cluster con Proxmox es totalmente trivial y se realiza con los siguientes pasos (tener en cuenta que todos los equipos que formen parte del cluster deben tener nombres diferentes):
En el nodo que será el master:
dell:~# pveca -c cluster master successfully created dell:~# pveca -l CID----IPADDRESS----ROLE-STATE--------UPTIME---LOAD----MEM---DISK 1 : 10.31.1.67 M A 1 day 05:11 0.08 30% 3%
Luego, el segundo nodo, que será el esclavo:
virtua:~# pveca -l local node '10.31.1.60' not part of cluster virtua:~# pveca -a -h 10.31.1.67 cluster node successfully created virtua:~# pveca -l CID----IPADDRESS----ROLE-STATE--------UPTIME---LOAD----MEM---DISK 1 : 10.31.1.67 M A 1 day 05:13 0.01 30% 3% 2 : 10.31.1.60 N A 01:57 0.00 11% 2%
Con lo anterior ya se conformó el cluster entre ambos equipos. Si se accede por web a https://10.31.1.67 se podrá ver el estado de ambos servidores así como las máquinas virtuales con las que cuentan los mismos (en este caso ninguna dado que aún no hemos creado). Lógicamente, desde dicha interfaz podrán apagarse, prenderse, reiniciarse y modificarse las distintas máquins virtuales.
Migración en vivo
Para la migración en vivo se necesita utilizar un servidor NAS/SAN en el que se alojen los discos de las máquinas virtuales. El motivo de esto es que para lograr la migración en vivo, lo único que se hace es mover la información que la máquina a ser migrada tiene en memoria, de un equipo al otro. Como el disco es compartido por estar en un servidor de almacenamiento no cambia nada allí; además la migración gracias a esto se hace muy rápido.
Como en este caso sólo se tienen dos servidores, se utilizará el nodo master como servidor de almacenamiento. Para ello, se creará un directorio que luego será exportado por NFS y agregado a la sección “Storage”. Lo primero se realiza de la siguiente forma:
dell:~# aptitude install nfs-kernel-server dell:~# mkdir /var/lib/vz/storage dell:~# vi /etc/exports /var/lib/vz/storage 10.31.1.60(rw,no_root_squash) 10.31.1.67(rw,no_root_squash) dell:~# /etc/init.d/nfs-kernel-server restart
Listo, sólo resta agregar el nuevo dispositivo de almacenamiento por medio de la interfaz web. Luego, cuando se cree una máquina virtual y un disco para la misma se debe guardar este último en el almacenamiento de red. Teniendo esto hecho, el paso de migrar las máquinas virtuales en vivo es tan sencillo que ni vale la pena que lo explique aquí.
TUN/TAP con OpenVZ
Experimentando con Proxmox me surgió la necesidad de instalar una máquina con OpenVPN. Para ello creé una con OpenVZ y cuando comencé con la instalación de OpenVPN noté que el dispositivo /dev/net/tun, que es el que permite crear interfaces virtuales, no existía en el sistema guest, aunque sí en el host.
La solución a este inconveniente está perfectamente documentada en la wiki de OpenVZ pero quise compartirlo con ustedes de todas formas. En el host ejecutar los siguientes comandos, reemplazando 101 por el ID de la máquina OpenVZ:
vzctl set 101 --devices c:10:200:rw --save vzctl set 101 --capability net_admin:on --save vzctl exec 101 mkdir -p /dev/net vzctl exec 101 mknod /dev/net/tun c 10 200 vzctl exec 101 chmod 600 /dev/net/tun
Listo, con esto alcanza para poder acceder al dispositivo en cuestión, sin necesidad siquiera de reiniciar el equipo.
