Quickemu: ejecuta rápidamente máquinas virtuales optimizadas de Windows, macOS y Linux

 (github.com/quickemu-project)
5 puntos por GN⁺ 2024-01-31 | 1 comentarios | Compartir por WhatsApp
  • Quickemu es un wrapper para QEMU que, al elegir el sistema operativo que se quiere ejecutar, gestiona automáticamente la configuración necesaria para crear una máquina virtual, permitiendo crear y ejecutar rápidamente VMs de Windows, macOS y Linux
  • quickget descarga automáticamente la imagen de SO upstream del sistema operativo deseado y crea el archivo de configuración de la VM, mientras que quickemu detecta el hardware y ejecuta la VM con una configuración adecuada para la computadora
  • El objetivo inicial era probar rápidamente distribuciones de Linux; las VMs y su configuración pueden ubicarse donde se quiera, como en un almacenamiento USB externo o en el directorio home, y no se requieren privilegios elevados para ejecutarlas
  • Actualmente soporta casi 1000 ediciones de sistemas operativos, incluidos macOS, Windows, la mayoría de BSD, FreeDOS, Haiku, KolibriOS, OpenIndiana y ReactOS
  • Funciona en hosts Linux y macOS, y ofrece funciones necesarias para usar VMs como SPICE, uso compartido de archivos, QEMU Guest Agent, VirGL, passthrough USB, reenvío de puertos, audio y arranque EFI y Legacy BIOS

Qué hace Quickemu

  • Quickemu es un wrapper sobre QEMU que gestiona automáticamente la configuración necesaria al crear máquinas virtuales
  • El usuario solo tiene que elegir el sistema operativo que quiere ejecutar, sin necesidad de especificar manualmente muchas opciones de configuración
  • Sus herramientas principales son dos
    • quickget: descarga automáticamente el SO upstream deseado y genera el archivo de configuración de la VM
    • quickemu: enumera el hardware del host y luego ejecuta la máquina virtual con una configuración optimizada para esa computadora

Punto de partida del proyecto y alcance actual

  • El objetivo inicial era permitir probar distribuciones de Linux rápidamente
  • Las VMs y su configuración pueden guardarse en cualquier ubicación, como un almacenamiento USB externo o el directorio home
  • Para ejecutar las máquinas virtuales no se requieren privilegios elevados
  • El soporte actual se expandió más allá de las distribuciones Linux hacia macOS, Windows, la mayoría de BSD y sistemas operativos no Linux
    • Algunos ejemplos soportados son FreeDOS, Haiku, KolibriOS, OpenIndiana y ReactOS

Sistemas operativos y hosts soportados

  • Como host, soporta Linux y macOS
  • Los sistemas operativos invitados incluyen
    • macOS Sequoia, Sonoma, Ventura, Monterey, Big Sur, Catalina, Mojave
    • Windows 10 y 11, incluido TPM 2.0
    • Windows Server 2022, 2019, 2016
    • Ubuntu y todos los flavours oficiales de Ubuntu
    • La mayoría de BSD y varios sistemas operativos no Linux
  • Soporta invitados ARM64, por lo que puede ejecutar VMs aarch64
    • En hosts ARM se ejecutan de forma nativa
    • En hosts x86_64 se ejecutan mediante emulación
  • La cantidad de ediciones de sistemas operativos soportadas llega a casi 1000

Funciones de VM

  • Ofrece soporte completo de SPICE, incluido el uso compartido del portapapeles entre host e invitado
  • Soporta varios métodos de uso compartido de archivos según el sistema operativo invitado
    • VirtIO-webdavd: uso compartido de archivos para invitados Linux y Windows
    • VirtIO-9p: uso compartido de archivos para invitados Linux y macOS
    • Samba: uso compartido de archivos para invitados Linux, macOS y Windows; requiere que smbd esté instalado en el host
  • Soporta QEMU Guest Agent, lo que permite acceder a un agente a nivel de sistema mediante comandos QMP estándar
  • En funciones gráficas y de dispositivos, soporta aceleración VirGL, passthrough de dispositivos USB y passthrough de tarjetas inteligentes
  • También incluye funciones de red y entrada/salida
    • Reenvío automático de puertos SSH hacia el invitado
    • Reenvío de puertos de red
    • Audio full duplex
    • Soporte para braille
    • Arranque EFI con o sin SecureBoot
    • Arranque Legacy BIOS

Flujo de inicio rápido

  • Después de instalar Quickemu, se crea y ejecuta una VM en dos pasos
  • Con quickget, se descarga una imagen ISO y se crea el archivo de configuración de la VM
quickget nixos unstable minimal
  • Con quickemu, se inicia la VM usando el archivo de configuración creado por quickget
quickemu --vm nixos-unstable-minimal.conf
  • Si se ejecuta quickget sin argumentos, se puede ver la lista de todos los sistemas operativos soportados

Documentación y referencias

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-31
Comentarios de Hacker News
  • Recomiendo https://virt-manager.org/. En mi entorno funcionó mucho mejor, y también soporta ejecutar QEMU en sistemas remotos por SSH
    Siempre lo usaba cuando antes administraba muchos hosts de VM distintos y VMs locales
    • virt-manager es uno de los programas más infravalorados que existen. Es potente y se termina usando muy seguido
      Hay que conocer al menos algo de la terminología básica de las VM, pero recuerda mucho a esas GUI de la vieja escuela repletas de funciones y potencia
      Si tus necesidades son simples o tienes menos experiencia con VM, Gnome Boxes usa el mismo backend pero ofrece una GUI más limpia. Al ser más simple, tiene menos flexibilidad, pero está bueno que después puedas abrir una VM de Gnome Boxes en virt-manager si necesitas ajustar una configuración que Boxes no expone
    • No es exactamente lo mismo, pero Quickemu también funciona bien a través de SSH
      Si lo ejecutas por SSH en un sistema remoto, hace “X forwarding” de la consola de QEMU a la sesión local de Wayland en Fedora
      Al principio pensé que iba a correr en modo headless, así que me sorprendió bastante ver que aparecía una ventana :)
    • Sorprende que un programa que solo configura cosas pueda ser tan importante y útil
      Hace pensar en cómo sería si la configuración estuviera separada del software que configura. En vez de aprender cómo cada programa de UI reinventó la rueda, podrías elegir tu administrador de configuración favorito
      Lo más cercano que tenemos hoy son los archivos de configuración en texto. Todos los programas que usan eso tienen que elegir un lenguaje específico y una ubicación de almacenamiento
      Una idea en la que he pensado bastante últimamente es una capa intermediaria de configuración. La UI de configuración visible para el usuario usaría el lenguaje o formato que se quiera, tomaría esos datos como única fuente de verdad y generaría los archivos de configuración que el software leería
    • libvirt y virt-manager no son más que interfaces de usuario simplificadas para el software real, QEMU y KVM. Resuelven el problema relativamente menor de parsear archivos de configuración y pasar las opciones correctas al binario de QEMU
      También tienen funciones de administración útiles, como arranque y apagado basados en archivos de configuración o acceso a consola serial, pero incluso eso es muy simple de implementar uno mismo con scripts de shell. El manejo de almacenamiento de libvirt es terriblemente verboso y complejo, y aun así no maneja bien thin LV ni ZFS
      A menos que quieras manejarlo al estilo corporativo estándar y no tengas intención de aprender el software base como QEMU o shell, o realmente necesites alguna función ambigua de libvirt, recomiendo usar QEMU directamente sobre KVM y escribir tus propios scripts. Vas a aprender más de QEMU que de un wrapper flojo en Python, y además vas a tener más control sobre el sistema
      Además, IBM/Red Hat parece haber prácticamente abandonado virt-manager mientras impulsa su nueva interfaz web, Copilot
      Quickemu resulta más interesante porque puedes ver unos ejemplos rápidamente y levantar una VM nueva enseguida, sin perder tiempo aprendiendo una UI grande y compleja
    • Me gusta el enfoque de pasar opciones de línea de comandos directamente a QEMU. Funciona bien para SO antiguos como Windows NT on MIPS o Ultrix
  • Vuelvo a dejar la advertencia de seguridad de la vez pasada que apareció[1]
    Esta herramienta descarga archivos arbitrarios de internet y luego compara sus checksums con otro archivo arbitrario distinto en internet[2]
    No son las mejores prácticas de seguridad. La forma correcta sería dejar committeadas en el repositorio las claves GPG de los desarrolladores de la distribución y verificar todos los archivos con esas claves
    Eso no significa que quiera menospreciar el esfuerzo de este proyecto para encontrar los flags correctos que hay que pasarle a QEMU para arrancar varios sistemas operativos
    [1] https://news.ycombinator.com/item?id=28797129
    [2] https://github.com/quickemu-project/quickemu/blob/0c8e1a5205...
    • ¿Alguien puede explicar por qué esto sería un problema de seguridad? Verificar con claves GPG sí es la mejor forma de garantizar autenticidad, pero no es muy distinto de lo que hace casi todo el mundo: descargar la ISO desde el propio sitio HTTPS de la distribución
      Además, agrega una verificación extra de coincidencia de hash que la mayoría ni siquiera hace
    • ¿Qué tan anticuada es esta práctica? ¿No se supone que TCP/TLS ya se encarga del checksum y de firmar el origen?
      En la época de FTP, el checksum y GPG eran imprescindibles. En HTTP/TCP, TCP ya se ocupaba de los reintentos y checksums, así que la necesidad de GPG era incluso mayor, pero ambos seguían siendo necesarios por los ataques de intermediario
      Pero si es HTTPS, ¿por qué sigue importando? ¿Acaso HTTPS no reemplaza ambas verificaciones y la validación de firma?
    • Además, el autor ingresó la contraseña de usuario con el micrófono encendido durante un live stream, usando un teclado mecánico
    • No parece que descargue “archivos arbitrarios de internet”, sino que usa solo las fuentes originales
    • Como referencia, macOS ahora sí hace verificación de firmas. En Windows no hay firmas disponibles
      Ojalá que el interés de Hacker News este año motive a alguien a implementar verificación de firmas para Linux
  • En macOS, UTM[0] hace esto bastante bien. También ofrece una pequeña galería[1] de imágenes preconstruidas
    0. https://mac.getutm.app/
    1. https://mac.getutm.app/gallery/
  • libvirt incluye virt-install, así que puedes crear rápidamente e instalar de forma automática Windows y varias distribuciones Linux. En Mac no lo he probado
    Un ejemplo reciente con Alma Linux sería este
    $ virt-install --name alma9 --memory 1536 --vcpus 1 --disk path=$PWD/alma9.img,size=20 --cdrom alma9.iso --unattended

Cuando vuelves después de tomarte un café, ya está corriendo una VM de Alma Linux con la instalación terminada. La lista de SO compatibles varía según la versión de libvirt, y se puede verificar así:
$ osinfo-query os

  • Si necesitas una imagen de disco de Fedora 39, también está virt-builder
    $ virt-builder fedora-39
    Más tarde puedes importarla a libvirt con virt-install --import

  • ¿virt-install descarga automáticamente la ISO? Si lo intentas, aparece este mensaje:
    $ virt-install --name alma9 --memory 1536 --vcpus 1 --disk path=$PWD/alma9.img,size=20 --cdrom alma9.iso --unattended
    ERROR Validating install media 'alma9.iso' failed: Must specify storage creation parameters for non-existent path '/home/foo/alma9.iso'.

  • No está claro cuál será el resultado. Me pregunto cuál será el nombre del host, cómo se particionará el disco, qué paquetes se instalarán y qué se configurará como zona horaria y distribución de teclado, entre otras cosas

  • Para hacer esto tuve que instalar libosinfo-bin

  • La comodidad de estas herramientas es excelente, pero si juntas los dos scripts principales, son unas 5000 líneas de Bash
    Quisiera revisarlos antes de ejecutarlos, pero no quiero leer 5000 líneas de Bash

    • En general estoy de acuerdo en que los scripts de shell no suelen ser agradables de leer, pero este código en realidad no está mal
      No sé si esto convenza a alguien, pero leí los scripts de Bash antes de ejecutarlos y estaban bastante bien estructurados. La funcionalidad está bien dividida en funciones, los nombres de variables son razonables, hay comentarios útiles, no hay flujos de control extraños ni llamadas indirectas, y el uso de comandos crípticos es mínimo. Está entre los scripts de shell más fáciles de leer que he visto hasta ahora
      Si piensas en lo que realmente hace este script, también tiene sentido que el código sea relativamente directo. En esencia, ejecuta un solo comando para iniciar QEMU. El resto del código inspecciona el sistema local para decidir qué argumentos pasarle a ese comando, o descarga algunos archivos si hace falta
    • ¿Hay alguna razón para tratar un script de shell de forma distinta al resto del software solo por ser un script de shell? ¿Lees el código fuente del kernel antes de ejecutar un SO? ¿Y el navegador web?
      No significa que debas ejecutarlo a ciegas, pero los criterios que usamos para elegir el software que ejecutamos normalmente no dependen de si estamos familiarizados con su código fuente
    • Si de verdad te preocupa y tienes tiempo, aunque te critiquen, también podrías conversar con ChatGPT sobre el código. Un prompt podría ser algo así:
      “You are a linux guru, and you have extensive experience with bash and all forms of unix/linux. I am going to be pasting a large amount of code in a little bit at a time. Every time I paste code and send it to you, you are going to add it to the previous code and ask me if I am done. When I am done we are going to talk about the code, and you are going to help me break it down and understand what is going on. If you understand you will ask me to start sending code, otherwise ask me any questions before you ask for the code.”
      He probado este método con código más corto, aun así de menos de 1000 líneas que seguían superando el límite del prompt, y funcionó bastante bien. Admito que últimamente ChatGPT se ha vuelto más flojo, y a veces hay que pedirle explícitamente que no sea perezoso y que dé toda la salida solicitada, pero en general explica código bastante bien
    • Creo que esto tiene que ver con la construcción de confianza en el software en general. Es una cuestión de cómo se establece la confianza y qué expectativas y responsabilidades existen para desarrolladores y usuarios
      La frase “muchos ojos hacen superficiales todos los errores” parece un cliché que para algunos usuarios detiene el pensamiento. Asumen que, como está abierto y se puede revisar, entonces está bien, e imaginan hordas de auditores de código verificándolo todo, cuando en realidad uno termina esperando más la malicia que la buena voluntad
      En Windows ha habido utilidades de tweaks durante décadas. Atraen a quienes creen que los desarrolladores de las “grandes empresas” no tienen incentivos para exprimir al máximo el rendimiento del sistema y que dejaron opciones fáciles y útiles para todos escondidas detrás de configuraciones rápidas o tweaks del registro. Me recuerda a TronScript, que por su historia y nivel de participación parecería pasar la prueba del olfato y por eso inspira confianza, pero bajo la bandera de la automatización oculta los detalles y hace que el usuario espere que tome buenas decisiones por él. Puedes profundizar, investigar qué pasa y por qué, y aprender, pero para mucha gente en la práctica no es tan distinto de un binario
      Por suerte, la mayoría de estas herramientas tiene una base de usuarios limitada, así que no vale tanto la pena comprometerlas. Si una marca concreta llega a usarse lo suficiente, puede pasar algo como lo de CCleaner de Piriform, al que le metieron una puerta trasera en 2017

  • Se ve interesante, pero para alguien que en Ubuntu solo ejecuta Windows 11 de vez en cuando con VirtualBox, ¿me puedes decir qué ventajas tendría?

    • Es difícil responder porque depende mucho de lo que hagas con la VM. Esto parece un wrapper de QEMU, una herramienta que intenta elegir configuraciones razonables para facilitar levantar una VM nueva
    • En particular está el tema de la aceleración por GPU. Ejecutar videoconferencias en Windows dentro de vbox es casi imposible, e incluso una app GUI apenas un poco compleja tiene bastante latencia
    • Parece más bien una alternativa a Gnome Boxes. Una herramienta que descarga imágenes actualizadas y proporciona configuraciones predeterminadas adecuadas para esa distribución o SO, con soporte adicional para SO complicados como Windows y macOS
    • Si realmente vas a ejecutar macOS, esa es una gran ventaja frente a instalarlo en VirtualBox o VMware. Ahí hay que parchear varias cosas, así que hacerlo funcionar es muy difícil

  • En Linux recomiendo mucho Incus/LXD. Ejecutar una VM es tan simple como esto:

    incus launch images:ubuntu/22.04 --vm my-ubuntu-vm

    Después de iniciarla, el acceso al shell se hace así:

    incus exec my-ubuntu-vm /bin/bash

    Incus/LXD también soporta contenedores de sistema

  • Hay una opción que me gusta pero casi no se menciona: systemd-nspawn. Ejecutas docker create --name ubuntu ubuntu:22.04 y luego usas docker export ubuntu para crear un tar a partir de cualquier imagen de Docker.
    Después, solo hay que descomprimirlo en /var/lib/machines/ubuntu. Hay que elegir una imagen que incluya systemd o instalar systemd dentro del contenedor. Por último, entras con machinectl start ubuntu y machinectl shell ubuntu.
    systemd-nspawn es muy simple y ligero, y emula muy bien una máquina Linux real. Si tomas cualquier partición raíz basada en systemd y la arrancas con systemd-nspawn, funciona tal cual

  • ¿Hay alguna cifra de cambio de rendimiento comparada con simplemente ejecutar una VM? Normalmente corro un guest Linux dentro de un host Linux, pero a menudo me decepciona el rendimiento del guest.
    Nunca he investigado cómo ajustar la experiencia de una VM, así que me da curiosidad cuánto me estoy perdiendo. ¿Es 5% más rápido? ¿100%?

    • ¿Cómo lo estás ejecutando? Si corres KVM/QEMU con la configuración adecuada, obtienes un rendimiento casi de bare metal

  • ¿Corre de forma nativa en Arm, o sea en Apple Silicon? ¿Qué tal con las versiones recientes de macOS? ¿Tiene aceleración gráfica? ¿Cómo maneja la red?

  • Me da curiosidad cuál es la diferencia con Proxmox y si las optimizaciones que hace aquí se pueden reproducir manualmente en mi entorno de Proxmox

    • Esto es muy, muy diferente de Proxmox. Proxmox está hecho para laboratorios y centros de datos que necesitan alojar muchos servidores como VM.
      Quickemu parece estar orientado principalmente a uso de escritorio