Hyper-V VS Proxmox VS VirtualBox para laboratorio casero

La batalla de los virtualizadores
La batalla de los virtualizadores

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?

  • .VHD
  • .VHDX

 

  • Soportadas en otro hyper-V.
  • Se pueden modificar con herramientas de terceros para importar en otros sistemas.

 

  • .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í

En caliente?*máquina origen encendia  Sí

 No

  • Se pude usar disk2vhd y pelearse con los drivers en el primer arranque

 Uso en producción No que se sepa.Probable uso por developers para testing  Sí
 Precio
  •  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.

Tipos de Virtualizador
Tipos de Virtualizador

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 VE
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.

Containers VS VM's - Imágen de Docker.io
Containers VS VM’s – Imágen de Docker.io

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.

Docker
Docker

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.

VirtualBox 4.3
VirtualBox 4.3

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.
  • 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.

 

9 comentarios sobre “Hyper-V VS Proxmox VS VirtualBox para laboratorio casero”

  1. Muy bueno tú artículo, estoy aprendiendo a usar Docker y veo que es muy parecido al virtualenvs en python, pero para todo el sistema operativo. Uso virtualbox para probar cosas en windows, no conozco muy bien esto de Hyper-V y Promox (sólo conocía WMware muy lento en mi ubuntu 14.04), pero pienso investigar y ponerme al día.

    Gracias por el artículo :-)

    1. Gracias, me alegro que te guste.

      Docker está genial y es muy rápido de montar usando docker hub (merece la pena registrarse), y sí, vienen a ser el mismo concepto de entorno de solo lectura y ejecución controlada que proporcionan los virtualenvs.

      Si usas ubuntu, el combo que propongo con vagrant y VirtualBox puede que te de la vida si necesitas probar otras distros.

      Vmware, si no vas a trabajar con esxi (el virtualizador baremetal), no lo utilices, tendrás que crackear software por aprender a usar un programa en vez de aprender conceptos y saber buscarte la vida.

      Suerte aprendiendo y no pierdas las ganas aunque no salga a la primera ;-)

  2. No sé ahora “el estado del arte” al respecto en 2017 y qué experiencias reales has tenido.

    Veo muchas cosas de Vagrant (+Chef y Puppet) , Ansible, Docker, ..
    No sé en proyectos reales y en entornos Windows como aplica, ni en entornos de desarrollos ni en entornos de producción, sobre todo considerando el rendimiento (algo

    crítico en Producción).

    Vagrant me suena a concepto similar de VM Depot (repositorio de máquinas virtuales en la nube https://www.genbetadev.com/programacion-en-la-nube/vm-depot-repositorio-

    de-maquinas-virtuales-de-microsoft-open-technologies – Ahora VMDepot + Bitnami está en el Azure Markeplace https://azuremarketplace.microsoft.com/en-us/marketplace/).

    Vagrant va más allá pues tienes los scripts *.sh para configurar ciertas tareas, lo que da más versatilidad.
    Esto me recuerda, para máquinas virtuales HyperV – VMWare, a que con Powershell (con cmdlet de HyperV o de VMWare) en Windows también se podría (con mucho esfuerzo

    por lo que vi) ir instalando una máquina virtual de manera “silent”. No sé si también ayudaría Chocolatey en estos casos.

    Me gustaría profundizar más sobre Vagrant + (VirtualBox o HyperV) para Windows pues por el tema de licencias no habrá unas cajas como tal, sino limitadas o de

    evaluación.

    Me pregunto: si Vagrant es sólo para desarollo, y Ansible va un paso más allá y es para DevOps.

    Docker no sé si está maduro y menos en Windows:
    https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/

    Four Ways to Transfer Files Into Your Docker for Windows Containers
    http://markheath.net/post/get-up-and-running-with-docker-for-windows

    Vamos, todo un mundo.

    1. Aloha preguntón

      El VM depot son máquinas linux en Azure que puedes desplegar, desde mi punto de vista es un clon de vagrant cloud, no ofrece nada más o aparentemente mejor (si usas Azure guay, si no, pues meh).

      A lo que te refieres de los .sh, vagrant lo denomina “Provisioning” (https://www.vagrantup.com/intro/getting-started/provisioning.html), no deja de ser la parte de configuración para dejar tú nueva máquina a tu gusto. Esta parte podrías hacerla con cualquier aplicación “devop” tan de moda en 2016 (ansible, puppet, chef…).

      Desde que escribí esto en 2015 Vagrant ha incluído imágenes windows en su repo
      https://atlas.hashicorp.com/boxes/search?utf8=%E2%9C%93&sort=&provider=&q=windows y el proveedor que más imágenes ha subido es el desarrollador/creador de Chocolatey (@ferventcoder) así que el combo que buscas probablemente funcione pero… yo usaría Docker.
      Por qué? pues porque la containerización (si es que esta es la traducción correcta) está cada vez más cerca del mainstream, porque la proxima versión de Windows Server (2016 desde TP5) la soporta por defecto y porque ahorrarse espacio/cpu/dinero es algo que les encanta a los jefes.

      En cuanto a tu última pregunta, aquí mi opinión… ámbos son herramientas de devops: una te despliega las máquinas (vagrant o docker), la otra te las configura (ansible).
      No son exclusivas, cada una sirve para sus cosas.

      Por otro lado, no veo a mis developahs preparando sus entornos sin impacientarse porque aquello no funciona, porque al final… https://devloop.blocdenotas.org/sysadmin-because/ ^^’

      /n

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *