Mostrando entradas con la etiqueta virtualizacion. Mostrar todas las entradas
Mostrando entradas con la etiqueta virtualizacion. Mostrar todas las entradas

Vagrant: Instalación y primeros pasos

Esta entrada la tenía pendiente desde que el otro día hablé con +Susana López Barreras sobre el tema. Así que por fin me decidí terminarla y publicarla. Servirá para ella y para más gente, espero.

¿Qué es Vagrant?

Vagrant es una herramienta pensada para facilitar la creación y configuración automática de entornos de desarrollo virtualizados. Aunque en sus orígines únicamente se podía usar con VirtualBox, actualmente ya es capaz de desplegar máquinas en sistemas como VMware, Amazon EC2, etc. La gran ventaja es que trabaja de la mano directamente con herramientas de centralización de configuraciones, tales como Puppet o SaltStack, de las que hablamos aquí en más de una ocasión. Es gracias a esta perfecta combinación donde reside el verdadero poder de Vagrant.

Instalación

Vagrant está disponible en los repositorios de la mayoría de distribuciones, pero yo personalmente recomiendo bajar el paquete desde la web oficial, Vagrantup.com, para disponer así de la última versión. Compensa tener la versión de la web oficial, ya que tiene importantes mejoras. Así que nos dirigimos a la parte de descargas y seleccionamos el sistema operativo que tengamos y lo descargamos. Yo personalmente me bajo la de Debian 64 ;-)
shell> wget https://dl.bintray.com/.../vagrant_1.6.5
Una vez la tenemos, simplemente instalamos el nuevo paquete,
shell> dpkg -i vagrant_1.6.5_x86_64.deb
Y desde este momento ya disponemos de Vagrant instalado en el sistema. Crear una nueva instancia de una máquina virtual a partir de ahora será muy sencillo y trivial.

Uso de Vagrant

Efectivamente, Vagrant, si no se emplea con SaltStack o Puppet, no es más que una forma diferente de crear máquinas virtuales en VirtualBox, por decirlo de forma sencilla. Aun así, es una forma muy cómoda, pues no necesitas realizar ningún tipo de instalación. Esta es la primero ventaja que tiene Vagrant. Si necesitas una máquina con un determinado sistema operativos, ya no es necesario descargar la ISO e instalarla, desde Vagrant es más sencillo.

Crear nueva máquina

shell> vagrant init
 A `Vagrantfile` has been placed in this directory. You are now
 ready to `vagrant up` your first virtual environment! Please read
 the comments in the Vagrantfile as well as documentation on
 `vagrantup.com` for more information on using Vagrant.
A continuación editamos dicho fichero (/tmp/Vagrantfile),
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
   config.vm.box = "ubuntu/precise64"
end
Dejándolo tal y como se muestra anteriormente. A continuación, simplemente,
shell> vagrant up
 Bringing machine 'default' up with 'virtualbox' provider...
  ==> default: Importing base box 'ubuntu/precise64'...
  ==> default: Matching MAC address for NAT networking...
  ...
Este comando hará todo lo necesario. Es decir, se descargará la pre-imagen de la máquina precise64 si fuese necesario, creará una nueva instancia de la máquina en VirtualBox (por defecto) y la arrancará. Para acceder a ella,
shell> vagrant ssh

Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-72-virtual)
...

vagrant@vagrant-ubuntu-precise-64:~$
Si necesitas otra máquina, cual sea, simplemente editas el fichero y la creas. Sin complicaciones. Existen multitud de máquinas libres para descarga en vagrantcloud.

Destruir máquina

La ventaja de Vagrant y que veremos en próximas entradas es el poder de la auto-creación, pero por el momento, si tras levantar tu máquina virtual y trabajar con ella varios días, finalizaste el trabajo y ya no quieres que te ocupe espacio, simplemente,
shell> vagrant destroy
 Are you sure you want to destroy the 'default' VM? [y/N] y
  ==> default: Forcing shutdown of VM...
  ==> default: Destroying VM and associated drives...

Más

Como era de esperar, puedes apagarla, volver a levantarla, suspenderla y un largo etcétera de funcionalidades, según lo que aporte el sistema de virtualización que emplees.
Leer más

kUbuntu VirtualBox Guest additions fail

Por motivos que todavía desconozco muy bien, terminé instalando un sistema kUbuntu en una máquina virtual. Si bien es cierto que fui usuario de KDE, hace años que lo dejé de lado, ya que cada vez cargaba más y más la máquina, para sacar el mismo provecho que XFCE.
El caso es que tras instalar la máquina, decidí instalar las Guest additions de VirtualBox para que vaya más fluida y pueda intercambiar datos de forma rápida y sencilla con el host anfitrión. Tras hacerlo (y por lo que parece todo terminar correctamente), reinicio la máquina tal como indican las instrucciones y al volver al sistema, no es lo que esperaba, los servicios se han instalado, pero no arrancan. El módulo del kernel no está cargado y además no se puede cargar. Si intento forzar el arranque obtengo lo siguiente:
shell> /etc/init.d/vboxadd start
Starting the VirtualBox Guest Additions ...fail!
(modprobe vboxguest failed)

shell> modprobe vboxguest
FATAL: Module vboxguest not found.
Esto no es desde luego lo esperado. El sistema tiene instalado el software, pero no funciona. Lo vuelvo a instalar y pasa exactamente lo mismo. Está claro que el fallo viene de otro lugar.
La ejecución de VBoxLinuxAdditions.run no está, lo que se dice precisamente depurada, y aunque falten un buen puñado de paquetes instalados, no avisa y lo que es peor, termina aparentemente bien. La solución,
shell> apt-get install dkms
shell> apt-get install build-essential
Tras la instalación de estos paquetes, volvemos a lanzar el instalador de las Guest additions.
shell> ./VBoxLinuxAdditions.run
Y ahora ya podéis reiniciar el sistema y debería de funcionar correctamente :-)

La entrada kUbuntu VirtualBox Guest additions fail la puede leer en Puppet Linux.
Leer más

Consejos para tus sistemas virtuales

Cada vez es más común el uso de máquinas muy grandes y potentes que luego virtualizan a otras más pequeñas, para así aprovechar mejor el rendimiento. En entornos grandes, donde la virtualización comienza a mandar desde hace unos años, se emplean grandes plataformas que permiten hacerlo y aislar las máquinas virtuales de las máquinas físicas. Bien empleen xen, vmware o Microsoft Windows Hyper-V. Proteger el entorno y por lo tanto todas las máquinas del mismo es importante, ya que si se consigue un acceso no deseado a una de las máquinas, por el fallo que sea, quizás éste se pueda extender a más máquinas. Por lo tanto os dejo una serie de consejos que espero os sean de utilidad a la hora de proteger y montar vuestra infraestructura virtual.
  1. Si empleas máquinas virtuales, piensa que no es la panacea de "esto lo aguanta todo". Por norma general la entrada/salida a disco será la que más se vea afectada. Tenlo en cuenta o podrás hacer que todas las máquinas fallen al compartir discos/cabinas.
  2. Usa sistemas de replicación. Un host físico es un único punto de fallo que involucra a muchas máquinas. Los sistemas de virtualización modernos permiten replicación y trabajo en HA.
  3. Aísla unas máquinas de otras si no necesitan tener acceso y visibilidad entre ellas. Los dominios cero permiten establecer VLAN's. Si un grupo de máquinas no necesita ver a otro, mejor aislarlas lo máximo posible. Una solución de VLAN es buena.
  4. Si puedes emplea tarjetas de red indipendientes para cada una de las VLAN's.
  5. Haz un control estricto de quién entra a las máquinas, pero más de quién accede al host físico, que es el que realmente controla todo.
  6. Usa únicamente las máquinas virtuales que necesites. Si una máquina no está siendo usada, no la tengas levantada "por que no consume". Esto puede traer problemas de seguridad. Apágala.
  7. Instala sólo el software que necesites en cada equipo. Piensa que cada nuevo servicio que instales es un nuevo servicio que hay que configurar, actualizar y mantener.
  8. Mantén tu máquina virtual al día. Aplica actualizaciones de seguridad y comprueba su estado. Que sea virtual no quiere decir que no necesite mantenimiento, es un servidor al fin y al cabo.
  9. Instala un firewall y establece políticas de acceso en cada una de las máquinas. Una máquina virtual no está protegida por su dominio cero, a nivel IP es igual de vulnerable. Así que controla lo que abres y a quién permites acceso.
  10. Evita dentro de lo posible la navegación desde las máquinas virtuales. Si no son para tal fin, úsalas sólo para lo que estén hechas. Los virus y demás fauna también las atacan.
  11. Controla a quién dejas acceso. Haz mantenimiento de cuentas de usuario y permisos.
Leer más

Cómo clonar discos en VirtualBox

Este post va dedicado a los amantes de VirtualBox, y en especial a aquellos que tienen que duplicar o exportar máquinas que ya tienen listas en sus equipos.
El problema viene originado cuando copias directamente el disco de una máquina y únicamente le cambias el nombre. Si haces esto, obtendrás un maravilloso error muy similar a éste cuando intentes arrancar la nueva máquina.




Cannot register the hard disk 'debian.vdi' with UUID {b02159ec-1596-b951-4ffc-49c99f25306e} because a hard disk 'debian.vdi' with UUID {b02159ec-1596-b951-4ffc-49c99f25306e} already exists in the media registry...
Básicamente, como podéis observar os está diciendo que el disco con el UUID XXX ya existe y por lo tanto no lo puede volver a usar. Desde hace tiempo, en GNU/Linux los discos se identifican por el UUID, un "número de serie" que garantiza que un disco va a ser único siempre (más o menos...).
Así que ya sabéis, si necesitáis duplicar el disco de una de vuestras máquinas, hacerlo directamente con VBoxManage y la opción de clonado que tiene,
shell> VBoxManage clonehd vuln.vdi debian.vdi
Oracle VM VirtualBox Command Line Management Interface Version 3.2.10_OSE
(C) 2005-2010 Oracle Corporation
All rights reserved.

0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone hard disk created in format 'VDI'.
UUID: edc388a1-ba0c-4d7b-9d53-895aca643829
Esto creará una copia del disco, pero le cambiará el UUID para evitar tener los problemas anteriormente comentados.

La entrada Cómo clonar discos en VirtualBox la puedes leer en Puppet Linux.
Leer más

Qubes OS, aprovechando xen en el escritorio

Hace años cuando comencé a investigar sobre los sistemas de virtualización y más concretamente sobre Xen. Una de las cosas más prometedoras que tenía era la posibilidad de independizar completamente una instancia de las otras, es decir, una máquina del resto. Esto ofrece como era de esperar una gran independencia. El mismo hardware, pero máquinas diferentes, por lo que si una se veía afectada, la otra seguiría estando bien. Las posibilidades eran muchas y muy diferentes, pero los requisitos también eran bastantes.
Sin embargo, hoy descubrí un nuevo proyecto, Qubes OS, que es un sistema operativo basado en GNU/Linux con los parches de Xen y que hace justamente lo descrito con anterioridad, aprovechando todas sus características.

Como los propios creados del sistema lo denominan, Qubes OS es "un sistema operativo diseñado para la seguridad".
Qubes is an open source operating system designed to provide strong security for desktop computing.
El método que ofrece para determinar que cada entorno es lo más seguro posible es la independencia que Xen ofrece para cada una de las máquinas que arranca (5 tipos por defecto) y que todas son accesibles y manejables desde un entorno gráfico.
  • random
    Máquina con datos volátiles para instalaciones y páginas en las que no confiemos al 100%. No almacena ningún tipo de información sensible.
  • social
    Máquina para uso de aplicaciones y acceso a páginas frecuentes. Sí almacena información sensible.
  • shopping
    Dominio virtual pensado para la realización de compras on-line y comercio electrónico.
  • bank
    Máquina con máxima seguridad. Sólo permite navegación HTTPS.
  • corporate
    Máquina que sólo dispone de un cliente VPN para conectarse a la red de la compañía y trabajar remotamente.
Como todo, aunque cada uno de los dominio virtuales esté 100% independiente del otro, el factor humano sigue jugando en contra de la seguridad de los datos que están ahí, lo que sí, es que se consigue una instalación con varias máquinas con diferentes perfiles.
Quizás en próximas versiones incluya una instalación de Windows (previo pago de licencia).
Más información, en su web oficial.
Leer más

Windows como escritorio de Linux


Para todos aquellos que solemos usar GNU/Linux estamos muy felices con él, pero siempre hay veces que es necesario tener un Windows a mano. No por que nosotros queramos, sino por que hay veces que se hace estrictamente necesario, bien por una aplicación que no hay versión para Linux, un fichero de office ;-), etc. También se puede dar el caso de un ordenador compartido en el que tras el login se puede iniciar una sesión Windows o Linux.
Ahora imaginémonos que todo el control de usuarios/contraseñas se las dejamos al sistema base (GNU/Linux) y el interfaz gráfico pues a elección de la persona que inicie. Así alguien podría decidir en un momento arrancar con KDE y en otro con WindowsXP. Esta opción daría una gran ventaja, ya que presentaría el equipo Windows como un escritorio más de inicio de sesión.

Por lo tanto, la idea es realizar una pequeña instalación de una máquina con VirtualBox, en nuestro caso y por que nos interesa, con Windows XP y luego agregarla como una opción más en el menú de GDM. Así, cuando un usuario decida arrancar con el escritorio Windows, se iniciará una instancia de dicha máquina virtual, la usará como un escritorio más y al finalizar simplemente volverá a la pantalla de login.
Como veremos a continuación, realizar esto es bastante sencillo, por lo que gracias a puppet replicarlo por una red de ordenadores, léase una facultad por ejemplo, sería muy sencillo.
Vamos a comenzar por el principio pues, realizando la instalación de los paquetes que nos hacen falta en nuestra distribución. En este caso, Debian ;-)
shell> apt-get install virtualbox-ose virtualbox-guest-additions
Al finalizar la instalación, simplemente arrancamos VirtualBox e instalamos el sistema que deseemos. En nuestro caso Windows XP. Creamos el disco (a poder ser, de tamaño fijo) y también le permitimos acceso a la red. Al finalizar toda la instalación, cerramos VirtualBox y seguimos configurando lo que nos falta.
Toca ahora añadir en el menú de GDM una nueva entrada con nuestro nuevo escritorio. Para ello creamos un nuevo fichero llamado WindowsXP.desktop bajo /usr/share/xsessions con el siguiente contenido:
[Desktop Entry]
  Encoding=UTF-8
  Name=Windows XP
  Comment=Use esta sesion para ejecutar Windows XP
  Exec=/usr/bin/Windows-XP-GDM
  Icon=
  Type=Application
Tras guardarlo en GDM ya aparecerá una nueva línea que nos permitirá iniciar sesión en el Windows virtual, pero en ningún lado le hemos dicho nada.
Sí, efectivamente el parámetro Exec del fichero WindowsXP.desktop es el que nos da la solución. Tenemos que crear dicho fichero (/usr/bin/Windows-XP-GDM) y el contenido del mismo será,
#!/bin/bash
VBoxSDL -vm WinXP -fullscreen
Simplemente le indicamos que arranque una estancia de una máquina virtual (en este caso WinXP) y a pantalla completa.

Al iniciar el usuario con este "nuevo escritorio" se iniciará la máquina virtual automáticamente y el usuario verá que su escritorio es realmente un Windows. Cuando la apague, automáticamente regresará a la ventana de login.
En breves intentaré dejar un manifiesto puppet que haga automáticamente este proceso para demostrar lo sencillo que sería distribuir sistema en una red de ordenadores.
Y por si alguien se lo está preguntando, gracias a VirtualBox la aceleración hardware ya no es un problema. Tras instalar la máquina virtual, instalamos los drivers (virtualbox-guest-additions) y todo irá muy fluido. Si te atreves a probarlo, comenta tu experiencia!
Leer más

BUG: soft lockup - CPU

Latencia de red (en ms)
Ayer me pasó algo curioso en unas máquinas virtuales bajo XenServer. Hay que decir que estas máquinas están virtualizadas en una infraestructura a la que no hay acceso y sobre la que no sabemos qué tipo de máquinas hay, a mayores de las nuestras. El caso es que todas las nuestras se estaban a ejecutar en mismo nodo del clúster y sin más ni más, comenzaron a subir el uso de CPU y su latencia de red. Gracias a #zabbix, su perfecta monitorización y sus alertas nos pudimos enterar al momento. Dejo un par de gráficas que representan las subidas experimentadas, que como se pueden ver, son considerables.
Consumo de CPU
Lo sorprendente es que la carga de las máquinas se originó sin motivo aparente, ya que no hubo nada "extraño" en la red ni en las máquinas, según las primeras palabras del proveedor. Sin embargo, tras revisar un poco de log's, nos encontramos con el siguiente fallo,
kernel: [12005213.706327] BUG: soft lockup - CPU#0 stuck for 64s! [kjournald:908]
kernel: [12005213.706327] Modules linked in: iptable_filter ip_tables x_tables firewire_sbp2 firewire_core crc_itu_t loop snd_pcm snd_timer parport_pc i2c_piix4 snd i2c_core joydev soundcore snd_page_alloc pcspkr parport processor evdev button psmouse serio_raw ext3 jbd mbcache usbhid hid sg sr_mod cdrom sd_mod crc_t10dif ata_generic ata_piix uhci_hcd 8139too ehci_hcd thermal libata floppy thermal_sys 8139cp mii usbcore nls_base scsi_mod [last unloaded: scsi_wait_scan]
kernel: [12005213.706327]
kernel: [12005213.706327] Pid: 908, comm: kjournald Not tainted (2.6.32-5-686 #1) HVM domU
kernel: [12005213.706327] EIP: 0060:[] EFLAGS: 00000282 CPU: 0
kernel: [12005213.706327] EIP is at cp_interrupt+0x23/0x28a [8139cp]
kernel: [12005213.706327] EAX: f7dea03e EBX: c1360aa0 ECX: c1360aa0 EDX: f6f60001
kernel: [12005213.706327] ESI: f6f62ba0 EDI: 00000020 EBP: f6f62800 ESP: e770fcf4
kernel: [12005213.706327]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
kernel: [12005213.706327] CR0: 8005003b CR2: f8260ffc CR3: 36f58000 CR4: 000006d0
kernel: [12005213.706327] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
kernel: [12005213.706327] DR6: ffff0ff0 DR7: 00000400
Lo más sorprendente que hemos encontrado ha sido la línea de BUG destacada en los log's y el posterior trace completo que hace. Tras investigar un poco a qué pudo ser debido, todo apunta a un fallo en la reserva de IRQ de las máquinas, lo que provocó un incremento de la carga de todos los equipos.
Por lo que hemos podido averiguar a posteriori, el proveedor sí nos reconoció que algunas de las máquinas del clúster efectivamente estaban consumiendo un gran ancho de banda, lo que afectó a las otras, que estaban mucho más ociosas. Se ve que la virtualización todavía no es 100% efectiva bajo ciertas circunstancias.
Leer más

virtualbox to xen disk ; xen to virtualbox disk

Muchas veces tenemos la necesidad de trabajar con máquinas virtuales y éstas pueden ser de muchos y diferentes tipos. No vamos a hablar aquí qué sistema es mejor para virtualizar a pequeña escala, pero sí podemos comentar un fallo que es común a todos, que emplean un formato muy concreto y específico para sus discos duros, haciéndolos incompatibles entre sí. Esto sí es un problema. Si tenemos un disco en formato Xen, no lo podremos ejecutar en vmware o virtualbox de forma 'simple', ni viceversa.
Por suerte, existen formas de realizar dichas conversiones. Vamos a ver a continuación cómo poder hacerlo,
  • VirtualBox to Xen
    shell> VBoxManage clonehd so_vbox.vdi so_xen.raw –format RAW
    
  • Xen to VirtualBox
    shell> VBoxManage convertfromraw -format VDI so_xen.img so_vbox.vdi
    
También te pueden interesar éstos otros 2 post's sobre conversión de discos entre plataformas de virtualización:
Leer más

Convertir disco VirtualBox a KVM

Si en un post anterior hablamos de cómo se podría hacer para convertir una imagen de VirtualBox a VMWare, en este caso vamos a ver cómo hacer también una conversión, pero de VirtualBox a KVM, otro sistema de virtualización también bastante común entre los usuarios.
Esta vez para hacerlo, tenemos que ejecutar 2 pasos.


  1. Convertimos la imagen DVI a RAW
    Esto va a tener un problema de ocupación de espacio en disco. Las imágenes VDI 'sólo' ocupan los datos que tenga, mientras las RAW ocupan todo el espacio definido. Esto implica que si la imagen DVI está ocupando actualmente 8Gb, pero tiene definidos hasta 40Gb, en formato RAW ocupará los 40 Gb.
    Con los discos actuales no debería ser problema, pero siempre hay que tenerlo en cuenta.
    shell> VBoxManage clonehd disk.vdi disk.raw --format RAW
    
  2. Convertimos la imagen RAW a QCOW2
    shell> qemu-img convert -f raw -O qcow2 disk.raw disk.qcow2
    
Leer más

Convertir disco VirtualBox a VMWare

En alguna ocasión fijo que os tiene pasado que tenéis que hacer una pequeña maqueta de un sistema con alguna funcionalidad en local para luego pasársela a un cliente o un amigo. Puesto que empleamos GNU/Linux, lo más lógico es que en el escritorio estemos usando VirtualBox. El procedimiento por lo tanto es bien conocido, creamos la máquina, la configuramos, la dejamos bien preparada y luego se la dejamos a nuestro amigo/cliente. El problema, el otro extremo de la cadena usa VMWare, la hemos liado!
Si es un amigo, todo puede tener solución, le contamos las ventajas y bondades de VirtualBox y se lo instala. Si es un cliente, mejor averiguamos cómo convertir la imagen del disco de nuestra máquina a VMWare, que además es muy sencillo. Simplemente hay que ejecutar este sencillo comando,
shell> vboxmanage clonehd \ 
       xpdisk.vdi \ # imagen VirtualBox
       xpdisk.vmdk \ # imagen VMWare
       -format VMDK \ # Nuevo formato aplicado
       -variant standard
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios