A principios de año tomé la decisión de cambiar VirtualBox por GNOME Boxes, la interfaz de KVM/QEMU orientada a poder ejecutar de manera rápida y sencilla sistemas operativos, principalmente distribuciones Linux. La decisión no fue por capricho, sino por el hecho de que, como dije en enero, VirtualBox 6.1 introdujo una serie de cambios en los drivers gráficos que empeoraron la experiencia, sobre todo porque perdí al emular sistemas Linux la característica de cambiar automáticamente la resolución de la pantalla según el tamaño de la ventana (o al menos yo no conseguí hacerla funcionar).

La migración a GNOME Boxes me permitió recuperar, gracias al uso de los gráficos SPICE, la característica de ajuste automático de la resolución según el tamaño de la ventana, algo que me resulta crítico cuando necesito estar pendiente de la máquina virtual y otra aplicación al mismo tiempo. Sí, GNOME Boxes fue un buen refugio, pero no carente de inconvenientes que hizo difícil la convivencia con la aplicación.

Fedora 33 Workstation ejecutado con GNOME Boxes

Quizá lo más destacado fueron las desconfiguraciones, que se producían sobre todo después de borrar una máquina virtual y cerrar posteriormente la aplicación. En muchas ocasiones descubría que GNOME Boxes no volvía a iniciarse, y la solución era de todo menos intuitiva. Yo he podido arreglarla solo porque tengo mucho rodaje en esto de GNU/Linux, así que muchas veces mi intuición me basta para encontrar soluciones a los problemas con lo que me topo, pero la verdad es que en esta ocasión el método no es ni mucho menos óptimo.

Para solventar las deconfiguraciones de GNOME Boxes hay que tirar de virt-manager, la interfaz gráfica profesional para KVM/QEMU que puede resultar un tanto áspera para los usuarios sin muchos conocimientos. Por lo general, lo que tenía que hacer era encontrar la máquina virtual mal borrada por parte GNOME Boxes y fulminarla definitivamente desde virt-manager. Sin embargo, para poder hacer eso hay que añadir antes al usuario común al grupo libvirt, cosa que se hace de la siguiente manera:

sudo usermod -a -G libvirt john

Lo segundo que eché de menos fue un soporte de red puente, o al menos un soporte de red puente como el que tiene VirtualBox, que suministra a las máquinas virtuales una IP procedente del DHCP del router. GNOME Boxes también ha ganado capacidades de red puente, pero mediante la red de libvirt, por lo que uno no puede acceder, al menos por defecto, desde un smartphone a un servidor ejecutado en una máquina virtual. Esto limita las posibilidades de Boxes para ser usado como entorno de pruebas.

Red puente en VirtualBox 6.1.16

El tercer inconveniente lo encontré en el soporte de EFI (o UEFI). Tanto GNOME Boxes como VirtualBox ofrecen la posibilidad de ejecutar máquinas virtuales sobre EFI, aunque en el caso del primero el proceso es más aparatoso al tenerse que editar la configuración en formato XML. Ambas soluciones de virtualización funcionan bien en este sentido, pero la aplicación de GNOME tiene la desventaja de ser incapaz de realizar instantáneas de una máquina EFI. Este problema fue reportado en 2017 y todavía no ha sido resuelto, así que este es otro detalle en el que VirtualBox siempre fue mejor, a pesar de que se suele usar BIOS clásica en las máquinas virtuales por razones de inmediatez y sencillez.

Habilitando el soporte de EFI en GNOME Boxes

Por último tenemos los gráficos, la razón que me hizo cambiar a GNOME Boxes. A lo largo del año 2020, el soporte de VirtualBox 6.1 ha ido mejorando enormemente, hasta el extremo de tener no solo flexibilidad con el ajuste automático de la resolución según el tamaño de la ventana (cosa que requiere de la instalación de las Guest Additions), sino que ofrece una fluidez muy superior gracias al uso de los drivers gráficos de VMware. No soy exigente con la fluidez de los gráficos de las máquinas virtuales mientras vayan rápido, pero no voy a negar que este nivel de fluidez da una sensación de “producto premium” muy agradable.

Gráficos de VMware en Ubuntu 20.04 con VirtualBox 6.1.16

En resumidas cuentas, VirtualBox ha vuelto a mi producción por la puerta grande, pero no como me gustaría, ya que dos meses después del lanzamiento del sistema, Oracle todavía no ha publicado el instalador RPM oficial para Fedora 33, así que me tengo que conformar con la versión suministrada por RPMFusion, la cual se va actualizando conforme vayan surgiendo nuevas versiones del software de virtualización.

24 de diciembre de 2020 y Oracle sigue sin publicar el paquete RPM para Fedora 33