He vuelto a empezar un curso, esta vez de Técnico de sistemas, donde nos dan un remix básico de terminología y uso de GNU/Linux y Windows Server 2012, como el temario ya lo tengo dominado, me estoy centrado en repasar contenidos de cara al LFCS y el 70-417.

En la academia disponemos de i7s con 8GB de RAM que soportan SLAT y por ende Windows 8.1 e Hyper-V o Proxmox y KVM, el caso es que el profesor parece no saberlo y estamos usando Windows 7 y VirtualBox.

En casa tengo ámbos montados pero llevo unos meses centrado en Hyper-V, ahora que he comparado ámbos en diferentes entornos quiero contaros las diferencias y posibilidades para un laboratorio casero (#homelab).

CARACTERÍSTICA	HYPER-V	VIRTUALBOX	PROXMOX
Virtualizador	tipo 1	tipo 2	tipo 1
Administración	GUI rdp al host MMC via RSAT powershell	GUI WEB via phpvirtualbox pantalla remota (rdp) contra el guest vboxtools solo en GNU/Linux	WEB consola web SSH RDP a guests
VMs exportables?	Sí .VHD .VHDX   Soportadas en otro hyper-V. Se pueden modificar con herramientas de terceros para importar en otros sistemas.	Sí .OVA .OVF   Estandar oficial iee para virtualización.	Sí  Estandar KVM, funciona en cualquier otro servidor KVM .
Importación de máquinas virtuales | discos virtuales?	Sí | Sí Desde sus formatos	Sí |Sí OVF y OVA	Sí Cualquiera
En caliente?*máquina origen encendia	Sí Disk2vhd	No Se pude usar disk2vhd y pelearse con los drivers en el primer arranque	Sí Varios métodos
Uso en producción	Sí	No que se sepa.Probable uso por developers para testing	Sí
Precio	Windows 8.1 Gratuito W2012r2 Hyper-V server core	Gratuíto	Gratuíto Pago por soporte

Hyper-V

En el artículo sobre Hyper-V y Ubuntu LTS ya dije que al estar haciéndose estándar es mejor jugar con él para estar prevenido, así que quizá deberías tener una máquina con 8.1 para tener algún servicio fantasma (la tipica db para pruebas, server de backups, el de monitorización, el servidor de logs) y así estar al día.

Una de esas cosas que aprendes estando al día es que cuando instalas la característica conviertes al Windows 8.1 en una máquina virtual y el sistema se convierte en un virtualizador tipo 1.

Si no es tu máquina principal te darás cuenta que gestionarlo varía entre sencillo e infierno dependiendo si usas Windows o Linux como máquina habitual.

Si usas Windows >Vista puedes utilizar las RSAT tools para añadir las mmc’s que permiten conectarte al servidor como si estuvieses delante.

Si usas GNU/Linux hay varias opciones:

1. Gestionar Hyper-V usando RDP.
   La forma aburrida de hacer las cosas.

   Léete nuestro post de sesiones concurrentes para poder conectarte con un usuario diferente al que tiene la sesión iniciada y poder gestionar Hyper-V desde la mmc original.

   Contras: Se abre una sesión de usuario nueva. Si tienes varias VM’s funcionando, el usuario que está delante de la pantalla lo nota dependiendo de la cantidad de RAM del sistema y el número de aplicaciones que se abren en esa nueva sesión.

2. Gestionar Hyper-V usando powershell via ssh.
   1. En el host Hyper-V:
      • Instala ssh y apt-cyg via cygwin y configura:
        1. Una tarea programada para actualización de todos los paquetes instalados.
        2. La configuración por defecto de sshd_config, fortifica el acceso.
      • Instala proxywinconsole para que actue como wrapper (intermediario) de la salida de powershell en la sesión cygwin.
      • Configura alias en el .bashrc del usuario con el que te vayas a conectar para:
        • Listar las máquinas virtuales existentes.
        • Gestionar energía de una máquína pasándole el nombre y el tipo de apagado.
        • …
   2. En el cliente linux desde el que te conectas.
      • ssh-copy-id usuario@ip-host-hyper-v por comodidad.
      • Ya está. Sí, y recuerda, GNU/Linux es complicado.

Proxmox VE

Proxmox es una de las alternativas, quizá la más viable, a VMWare ESXi y, sin lugar a dudas, a Hyper-V, ofrece unas características similares sin los costes asociados por licencias de aquellos, aunque deberías comprar planes de soporte en función del número de incidencias que quieras que te cubran anualmente y las necesidades de tus sistemas.

Basado en Debian, con soporte para OpenVZ y KVM ofrece las necesidades habituales de un sistema listo para producción como clusterización (soporta todos los tipos de montaje habituales), autenticación via LDAP o AD, roles, alta disponibilidad.

La diferencia entre KVM y OpenVZ es, a grandes rasgos, que KVM sirve para virtualizar al uso y según costumbres habituales (como en Hyper-V o VMWare) máquinas completas, mientras que OpenVZ permite crear «contenedores» aislados utilizando componentes compartidos como el kernel o una instantánea de un sistema de ficheros.

Esto reduce el uso del sistema, permite virtualizar entornos complejos e integrados con cargas y requisitos bajos.

Seguro que en los últimos meses has oido hablar de Docker, es un sistema similar basado en un fork de OpenVZ llamado LXC que, a diferencia de aquel, está integrado en el kernel, por lo que Docker permite usar cualquier kernel para cualquier contenedor, mientras que OpenVZ está limitado a los kernels de los que se disponga en ese momento. A día de escritura: 2.6.32

He encontrado un artículo en au courant techology que habla, a grandes rasgos, sobre las diferencias en los sistemas de containers habituales.

Supongo que si has leído lo anterior entenderás el hype alrededor de Docker, ya que servicios como OVH, Amazon o Google Engine podrían ofrecer sus servicios con una carga, necesidades y consumos mucho menores.

Por si te lo preguntas, SÍ, puedes usar Docker en Proxmox, pero hazlo bien:

• Crea una máquina KVM con tu sabor favorito (el hype de Docker ha llegado de la mano con el de CoreOS).
• Usa Docker desde esa(s) VM(‘s).

VirtualBox

Virtualbox es la única opción tipo 2 de la tabla comparativa de arriba, en algunas ocasiones me lo he encontrado en medio de algunos procesos productivos, o bien como plataforma para testing o como medio para licenciamiento fraudulento.

Centrándonos en el medio para testing «casero», proporciona la mayoría de las opciones de los virtualizadores tipo 1, dependiendo de la cantidad de RAM de tu sistema podrás hacer otras cosas mientras estás haciendo pruebas o no.

Y por otras cosas me refiero a usar Chrome con más de 20 pestañas abiertas o ver un mkv desde una unidad de red.

Lo mejor que ofrece VirtualBox es justo aquello que no puede controlar, la comunidad alrededor del programa. Gracias a una documentación bastante decente hay proyectos que agregan características muy útiles. Mis favoritos:

• El pack de extensiones oficial.
  • Soporte USB 2.0. Los usb’s son pasables a la VM.
    Shame on you Hyper-V!.
  • Soporte vRDP con autenticación. Permite conectarte via RDP a la máquina virtual exponiendo el puerto de la «pantalla remota» en el host.
    Shame on you Hyper-V!.
• phpvirtualbox · Permite gestionar diferentes instancias de VirtualBox desde una única página web.
  Shame on you Hyper-V!.
• VirtualBoxHeadlessTray · Muchas ventanas abiertas? Preferirías que la pantalla se minimizase a notificaciones en vez de a la barra de tareas? Te gustaría controlar VirtualBox desde un menú contextual? Esto es para tí.
  Sólo Windows.
• VBoxTool · Sólo para GNU/Linux. Permite gestionar y controlar el estado de las VM’s sin tener que usar vboxmanage.
  • En Mac, hasta la versión 4.2.0, había que scriptear el inicio de las VM’s que quisieras. Desde esa versión de VirtualBox ya no es necesario.
• Vagrant · Vagrant permite instalar entornos integrados (iguales) basados en máquinas virtuales GNU/Linux en un par de comandos.
  • Caso práctico: necesitas 3 VM’s Ubuntu 14.04.1 configuradas de una manera específica (apache, base de datos, archivos), qué harías usualmente?
    • crear tres nuevas máquinas virtuales.
    • instalar ubuntu en al menos una de ellas.
    • duplicar la máquina y cambiar parámetros.
    • Todo esto, al menos, consume 30′ de tu tiempo.
      ¿Y si te digo que con vagrant podrías hacerlo en 3′?
  • Instalas vagrant (se presupone que virtualbox está instalado).
  • Creas un directorio para tu proyecto y te dirijes allí en la consola.
  • Teclea: vagrant init ubuntu/trusty32
  • Modifica el nuevo archivo VagrantFile para que se cumplan las específicaciones de tu máquina (nombre, ip, configs de VirtualBox) y se lancen los procesos de instrumentalización que tengas implementados (aquí entran el script, Ansible, Chef o Puppet de turno).
  • Por seguir el ejemplo, triplica y modifica las configs para adaptar las máquinas que necesitas.
  • Teclea: vagrant up en uno de los directorios, espera a que se descargue la imágen oficial, una vez haya terminado y empiece la configuración automatizada, puedes abrir otra shell, dirigirte a los directorios de las otras máquinas y volver a lanzar vagrant up.
  • Hazte un café, al volver, dependiendo de la longitud del script de aprovisionamiento, deberías tener varias máquinas listas para jugar.

CONCLUSIONES

1. Hay que estar al día y no perderse nada, tener varios sistemas en el mismo homelab es viable por no decir necesario.
2. VirtualBox ofrece la mejor solución en términos de usabilidad general, con el plus de una comunidad activa detrás de diferentes proyectos alrededor.
3. Proxmox debería ser el estándar de virtualización en lugar de VMWare y su incomprensible lista de precios, productos y capacidades. Dicho lo cual sigo detrás del VCP y el ICM 5.5 por el hype creciente con la virtualización.
4. En clase, mi profe debería estar usando Proxmox en vez de VirtualBox, y si sigue en sus 13, debería al menos usar Pantalla remota o screen y ssh para «solucionar dudas» usando el proyector.