Para esto sirven las máquinas virtuales: un artículo sobre casos que podrían haber echado a perder una instalación nativa y algo más

Las máquinas virtuales existen desde hace mucho tiempo, y, como todo, cumplen una función. Últimamente estoy viendo a cada vez más gente usarlas justamente para instalar Linux, ya que con Windows es más complicado gestionar algunas cosas, pero también las podemos usar como caja de arena, como un entorno seguro en el que hacer pruebas.

Yo usé mi primera máquina virtual, si no recuerdo mal, en 2006, y lo hice para probar Linux antes de dar el salto real. Hoy en día tengo una con Windows, otra con Manjaro y otra con Ubuntu Daily Build, pero también hago otras pruebas. Unas veces por ver las novedades, otras por curiosidad… y otras para evitar romper algo de mi sistema operativo, y aquí expongo algunos estropicios que he visto yo o algún conocido y que podrían haber echado a perder, e incluso lo hicieron por no tomar precauciones, una instalación nativa.

Usar máquinas virtuales para probar antes de instalar

Yo uso en mi equipo principal Manjaro, y tengo otra máquina virtual con Manjaro para probar ciertas cosas. ¿Por qué? Justamente porque antes no lo hacía, y una vez, probando algo con WINE y Bottles, algo salió mal, muy mal, y decidí instalar de cero. Hace ya un par de años de eso, y no lo he vuelto a hacer gracias a esta máquina virtual. Podría haberlo arreglado sin reinstalar, pero mis manías me impiden trabajar con algo que podría tener algún problemilla.

Aunque hacerlo en virtual no siempre es una prueba fiable de cómo deben ser las cosas, yo pruebo mucho software en esa máquina virtual. ¿Que quiero instalar un programa y veo una larga lista de dependencias? Lo pruebo en mi máquina virtual de Manjaro. Luego puedo eliminar software principal, dependencias y huérfanos sin miedo a romper nada importante. Total, si algo va mal, la reinstalo.

Archivos eliminados por accidente

Cuando un conocido se cargó /bin

Conozco el caso de alguien que estaba probando a crear su propio script y, para lanzarlo directamente desde el terminal, no se le ocurrió otra cosa que añadirlo a la carpeta /bin. Lo hizo con privilegios y desde el terminal, y lo copió con cp. Viendo que algo no terminaba de convencerle, se propuso a hacer el camino inverso, y básicamente repitió el comando, pero con rm. Sin fijarse en lo que le decía la primera vez, lo repitió con la flag -f. Explicándolo con la canción del mamut chiquitito, «¿y qué pachó? ¡Mi****! ¡La carpeta /bin se hiso mi****!».

La carpeta /bin contiene gran parte de los ejecutables de un sistema operativo basado en Linux, y sin ella no se puede hacer prácticamente nada. Al haberla eliminado desde terminal, no hay papelera desde donde reciclar. Pasó en una máquina virtual, por lo que no se perdió mucho.

El archivo ubuntu.sources desapareció

Esto me pasó a mí y además recientemente. En Ubuntu y otras distros, hay un archivo de fuentes llamado sources.list, pero en 24.04 habrá cambios y estará en otra ruta y con otro nombre. Esto me pasó en una de mis máquinas virtuales que uso para ver las novedades, más concretamente en la de la Daily Build de Ubuntu. Quería probar WARP, y me estaba dando fallo en el repositorio. Fui a eliminarlo manualmente, me metí en la nueva ruta, le di a eliminar y… bye, bye, ubuntu.sources; me equivoqué de archivo. Ahora bien, esto sí tiene solución y pasa por ir a Software y actualizaciones, volver a marcar las casillas y recargar.

Paquetes no disponibles

En mi Manjaro virtual voy a todo trapo, no me preocupo porque para eso está. Ahí instalo y elimino indiscriminadamente, y en alguna ocasión he intentado hacer algo, como instalar software de AUR, y he visto como da fallo. Eliminar los huérfanos suele ir bien, pero en ocasiones no lo hace. O sí, pero el caso es que no me permitía compilar porque no encontraba un paquete. Podría haberme dado un susto en nativo, pero no en una máquina virtual no. Además, la solución pasó por instalar ese paquete y volver a intentarlo.

El arranque secuestrado por Android

El arranque y algo más. No recuerdo muy bien cómo sucedió, pero me dio por probar Android en un USB, o algo así. Yendo a la mía y sin consultar, hice un «to p’alante» e hice dualboot… o no. En uno de los pasos, el ahora descontinuado Android-x86 consultaba si instalar el arranque, y terminé con el de Android y el de Ubuntu, ambos.

Hace mucho de esto, y yo sabía mucho menos que ahora. Al intentar eliminar el arranque de Android, lo que hice fue cargármelo todo, y al intentar iniciar no encontraba ninguna unidad. Tampoco sabía cómo recuperar portátiles, así que le llevé el mío a un amigo para que lo reparara un conocido informático. Era «x86», y no habría pasado nada de esto si hubiera usado una máquina virtual.

Máquinas virtuales para probar sistemas rápidamente

DistroSea a mí me hace papel. Puedo ir a su página, iniciar un sistema, hacer algunas capturas y escribir un artículo con una imagen propia, por ejemplo. Pero si quiero realizar pruebas exhaustivas, no me vale. El rendimiento no es muy bueno, y en cualquier momento pueden tirarte para hacer espacio. Muchas veces tampoco es necesario instalar un sistema operativo ni crear un Live USB. En un punto medio están las máquinas virtuales que permiten probar sin instalar y, si el equipo lo permite, con un rendimiento medio.

Para qué nos sirven las máquinas virtuales

Las máquinas virtuales no sirven para todo. Por ejemplo, si queremos probar una distribución como Vanilla OS o BlendOS, que son compatibles con aplicaciones de Android, no podemos hacerlo en ellas. Virtualizar en un entorno virtualizado no suele ir muy bien, o no va en absoluto.

Tampoco merece la pena instalar y usar programas pesados o juegos en máquinas virtuales, a no ser que tengamos un equipo muy potente que nos permita darle recursos al sistema huésped. Aún así, todo esto es mejor hacerlo en nativo.

Las máquinas virtuales son útiles

Las máquinas virtuales son útiles, y merece la pena que nos acostumbremos a usarlas para no correr riesgos. Entre los programas que permiten virtualizar y se usan mucho en Linux, GNOME Boxes y VirtualBox están al frente de cualquier ránking. Son un cinturón de seguridad que en este caso salvan a un sistema nativo, entre otras cosas.