... pero si el S.O. es Windows, mejor libvirt

¿De que estamos hablando? De las cajas (gnome-boxes) del otro día. En vista del éxito logrado con Ubuntu, y posteriormente con Fedora LXDE, que estuve probando, me dicidí a instalar Windows XP en cajas. ¿Por qué? Simplemente, mantengo una máquina virtual de Windows que ocupa 60GB, mucho volumen para lo poco que se hace en ella. Ese tamaño se debe a que la inicial que me planteé en VirtualBox, de 10GB, no duró ni dos semanas, ya que Windows depredaba espacio a gran velocidad. Esa situación me llevó a generar una imagen de tamaño fijo de 60GB que he heredado hasta hoy, unos 8 años después. Esos 8 años también han provocado que esa máquina este llena de material "sobrante" que ya no es necesario en absoluto, así que lo mejor, pensé, era empezar de cero en una caja instalando solo lo imprescindible:
1. SPSS para hacer CHAID, hasta que domine la técnica en R.
2. Corel Draw 12, para recuperar las imágenes que en el pasado procesamos en Corel PhotoPaint y los vectores generados en Corel Draw.
3. MSOffice 2007, para mandar ficheros "compatibles" a algunos co-usuarios que me rodean, sobre todo cuando hay tablas en ficheros docx.
Esto supone la instalación de Windows XP, 7z como compresor, AVG como antivirua gratuito, añado Gimp para trabajar con el resultado de la recuperación de los cpt de Corel PhotoPaint, Corel y MSOffice (y también Libreoffice 4.4.4 de extraperlo). Sin embargo la instalación (cuatro intentos diferentes) de Windows XP en cajas han generado imágenes que no se han podido abrir gráficamente, pero que eran accesibles desde virt-manager. Además estas instalaciones eran verdaderamente lentas y colapsaban de vez en cuando el sistema (16GBs de RAM).
Por ello he terminado haciendo la instalación en libvirt a través de virt-manager, generando una imagen de 30GBs.
Al intentarla abrir en cajas, una vez terminada la instalación da un error

Es decir, la configuración básica no manipulable de cajas no permite generar una imagen "productiva" de Windows y la instalación mucho más depurada y a gusto del consumidor a través de libvirt nos da una imagen incompatible con las características básicas de cajas. En resumen, las cajas están muy bien para distribuciones de Linux, pero no es productivo —aun— para Windows.

¿Qué he logrado? Una imagen instalada originalmente en formato qcow2, sin herencias ocultas de VirtualBox y la he reducido a 30GB; podré ahora eliminar las copias de la imagen en producción hasta ayer (60GB más la pieza de museo original de 10GB) y liberaré 40GB del DD. Por supuesto, eso es lo de menos, por que hoy los GBs son muy baratos y es un volumen pequeño; la instalación directa a través de virt-manager me ha permitido ver muchos entresijos del sistema y aprender nuevas formas de intercambio entre la maquina virtual y el sistema anfitrión, la comunicación con ISOs y con ficheros directamente.

PD. La instalación de todo el sistema y las aplicaciones ha sido mucho más rápida en la máquina virtual que Windows directamente en el hardware, ya que nos hemos basado en ISOs, conexiones directas a red y ficheros en dispositivos USB y no a CDs o DVDs.

ACTUALIZACIÓN: La imagen generada es perfectamente trasladable a otras máquinas con libvirt y funciona perfectamente.

Añadir ISOs a una máquina virtual en Fedora

Desde que uso Fedora he utilizado el gestor gráfico de máquinas virtuales diseñado por Red-Hat —virt-manager— y dejé de usar VirtualBox. La razón de que lo use es que se trata de software libre y que no pertenezca a Oracle, no por que sea más fácil de usar, que no lo es. VirtualBox es más fácil, tiene algunas características que virt-manager aun no tiene —o yo no se encontrar— y lo había usado años, sobre todo cuando era dependiente de algunos programas de Windows.

Desde que uso virt-manager, cada vez me es menos necesario acudir a Windows y realmente ya no voy casi nunca. Sin embargo, como ya había señalado, sí tenemos un problema; mejor dicho, dos, que se resumen en uno, COREL. Primero, no podemos abrir las imágenes que tenemos guardadas como CPT (Corel Photo Paint); años de manipulación de imágenes perdidos. Segundo, y este es nuevo, no podemos importar los dibujos vectoriales que habíamos realizado hace muchos años con Corel Draw a través de uniconvertor a Inkscape.

Esto nos ha obligado a recurrir al último Corel Draw que utilizamos, y lo que nos costó encontrarlo, ya que fue Corel Draw 12, del año 2004, y todo el material antiguo ya lo habíamos tirado a reciclar. Por suerte, los materiales originales los guardamos y pudimos disponer de ellos. Y aquí apareció un nuevo problema...

...mis máquinas virtuales son conversiones heredadas de virtualBox y jamás he instalado nada nuevo en ellas. No he puesto a disposición de la máquina una unidad CD-ROM ni directorios compartidos. Sin embargo es muy sencillo y se puede hacer y deshacer en caliente. Lo más fácil es generar un ISO del CD original —en brasero, K3B o terminal, según gustos— y en la configuración de la máquina virtual añadir nuevo hardware (abajo de todo).

En la primera casilla, "storage" o almacenamiento, marcamos en "Elija administrado", localizamos localmente el ISO, y lo configuramos como Dispositivo CDROM.

Aparecerá en el sistema huesped —Windows XP, en este caso— el nuevo "dispositivo", que es el ISO, y ya podemos instalar perfectamente en la máquina virtual.

Sí, es algo básico, pero realmente no lo había necesitado hasta ahora, y probablemente no lo necesite de nuevo, una vez instalado Corel 12.
Descontando estos casos de recuperación de ficheros antiguos de formatos propietarios, las máquinas virtuales las uso para probar diferentes escritorios; de windows solo recurro ocasionalmente a VirtualDubMod y funciona para lo que quiero con wine.

Fedora 21 a través de FedUp. Solución para las "broken dependencies"

Como había señalado en la entrada anterior, la actualización por FedUp había funcionado "casi" perfectamente, y que en la propia actualización, antes de empezar la sustitución de paquetes, la aplicación avisaba de cuáles presentan dependencias rotas, con el desalentador aviso de que instalásemos bajo nuestra responsabilidad ("Continue with the upgrade at your own risk").
A pesar de ello, todo va como la seda... hasta que llamas a uno de esos paquetes, en mi caso R, que es parte intrínseca de mi trabajo. La respuesta es:

Es decir, hemos tropezado con la dependencia rota.

Para solucionarlo simplemento desinstalé a través de yumex (YumExtender) R (R-core, R-core-devel, R-devel, R-java-devel) y luego reinstalé con yum

su -c 'yum install R-core R-devel' # suficiente; los otros son dependencias

Y con eso ya funcionaba. Eso sí, en vez de ser la versión 3.1.2 "Pumpkin Helmet" que ya estaba instalada en Fedora 20, la que está ahora es la 3.1.1 "Sock it to Me".

Es decir, la preparación de Fedora 21 quedó congelada antes de alguna de las actualizaciones de Fedora 20 y hay alguna "regresión" de versión.

Este problema solo me ha aparecido en R, Virtual Manager (virt-manager) y HandBrake. Los dos primeros se han corregido de la misma manera (desinstalación y vuelta a instalar) y handbrake no lo he necesitado, así que no lo he vuelto a instalar (aun).

Y de todas maneras dos días después ya se ha actualizado R a 3.1.2. en Fedora 21.