Por qué reemplazamos Firecracker por QEMU

• Hocus (una alternativa autoalojable a GitPod/GitHub Codespaces) reemplazó Firecracker por QEMU

Firecracker está optimizado para cargas de trabajo de corta duración que arrancan y terminan rápido

• Un hipervisor de microVM ligero, rápido y seguro, usado en AWS Lambda
• No es tan ligero
  • No ofrece la "gestión dinámica de RAM", algo esencial para cargas de trabajo de larga duración. La RAM asignada una vez no se devuelve al host
  • Tampoco tiene una función para devolver almacenamiento al host. Aunque se creen y luego se eliminen archivos grandes dentro de la VM, no se recupera espacio libre en el host. Sigue ocupado hasta que se elimine toda la unidad de la VM
  • No tiene soporte para GPU ni ofrece IO de disco de alto rendimiento

QEMU tampoco es perfecto

• Hay demasiadas cosas que configurar
• Para devolver la RAM no utilizada, el host tiene que resolver 3 desafíos
  • Saber siquiera que esa función existe (se llama free page reporting y hay que activarla manualmente)
  • Entender la función DAMON de Linux, saber para qué sirve y cómo configurarla, y compilar un kernel de Linux que la soporte
  • Hay que evitar usar Transparent Huge Pages en el guest; de lo contrario, la VM no devuelve grandes cantidades de memoria
• Tomó 2 meses probarlo
  • Leer el código de Firecracker/QEMU
  • Incluso intercambiar correos con el desarrollador para configurar DAMON
    → (El desarrollador de DAMON es el coreano SeongJae Park.)

Conclusión

• QEMU tiene las funciones necesarias para operar cargas de trabajo de propósito general
• Pero configurarlo requiere tiempo y paciencia
• Para Short-lived, Untrusted Workload, Firecracker es una buena opción
• Pero si quieres ejecutar tu entorno de desarrollo en una VM, puedes usar Hocus (nosotros ya hicimos el trabajo difícil)

[tujuc]

Está bien que presenten su producto, pero también da la impresión de que es mejor simplemente usar los servicios de AWS...
Como dijo ssssut, es un servicio que también funciona en Fargate, así que no creo que llegue a ese extremo.

Todavía no entiendo cuál es el problema de no liberar la memoria. Aunque haya contención de CPU, la aplicación solo se vuelve más lenta y no hay problema para que arranque, pero con la memoria no hay solución...

[ssssut]

Actualización: Firecracker se usa no solo en AWS Lambda, sino también en ECS Fargate para cargas de trabajo de larga duración.

[GN⁺]

Opiniones de Hacker News

• Firecracker se usa en CodeSandbox para alojar entornos de desarrollo, pero creo que también podría usarse para tareas de larga duración.
• QEMU tiene un objetivo inspirado en Firecracker llamado microvm, un tipo de máquina mínimo sin soporte PCI ni ACPI, diseñado para huéspedes de corta duración.
• Cloud-hypervisor es otra opción similar a Firecracker que admite recuperación de memoria y otras funciones.
• Firecracker tiene un dispositivo globo que puede inflarse y desinflarse para recuperar memoria desde el sistema host.
• Este artículo menciona las limitaciones de Firecracker, pero no ofrece mucha información sobre QEMU.
• Fly usa Firecracker para alojar procesos de larga duración.
• Quiero que las VM se integren de forma más inteligente con el host, incluyendo deduplicación de caché de bloques e integración de copia cero.
• QEMU, a diferencia de Firecracker, puede hacer bind mount de volúmenes, aunque esto puede representar un riesgo de seguridad.