VirtualBox y actualización de kernel. Qué hacer si akmod no recrea el driver para el nuevo kernel

Personalmente no me había enfrentado a este problema desde hace mucho tiempo, por que desde que utilizo virt-manager nunca me he visto en la situación de que no arranque la máquina virtual. Sin embargo, convencí a un compañero para que cambiara de su Ubunto 10.10 a Fedora 22. Por supuesto, Ubuntu 10.10 hace mucho tiempo que no tiene soporte y no se actualizaba, así que no se veía en el mensaje de que falta kmod desde hace tiempo. Sin embargo, con Fedora la actualización es continua y se encontró con que la máquina virtual no arrancaba con el kernel 4.08.
La orden habitual de arreglo

'dnf install kmod-VirtualBox-$(uname -r) kmod-VirtualBox'

no funcionó por que no encontró en los repositorios kmod-VirtualBox-4.0.8-300.fc22.x86_64.x86_64 (kernel actual), ya que solo disponemos de los módulos de VirtualBox para 4.0.5-300 y 4.0.2-300.

La solución puede ser la instalación de los akmods, que chequean la existencia de un kmod, y si no lo hay lo genera automáticamente. Ejecutamos

'dnf install akmod-VirtualBox kernel-devel-$(uname -r); akmods'

y la respuesta fue

El paquete akmod-VirtualBox-4.3.28-1.fc22.x86_64 ya se encuentra instalado, omitiendo.
El paquete kernel-devel-4.0.8-300.fc22.x86_64 ya se encuentra instalado, omitiendo.  # ESTO YA LO SABÍA, por que tengo instalados los devel, compilador de c ...
Dependencias resueltas.
Nada por hacer.

Es decir, ya estaba instalado el akmod. ¿Por qué no se había generado el kmod? Pregunta interesante. De todas maneras Linux nos da la solución en el terminal

Hint: Some kmods were ignored or failed to build or install.
You can try to rebuild and install them by by calling
'/usr/sbin/akmods --force' as root.

Así que ejecutamos como administrador

/usr/sbin/akmods --force

y para asegurar reiniciamos el ordenador.

Listo. Máquina virtual funcionando.

... 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.

virt-manager: episodio 3. Cambios internos

Mientras estaba disfrutando de unas mini-vacaciones en Semana Santa me asaltó una duda que no pude comprobar (en el portátil no llevo máquinas virtuales). ¿Cuál será la respuesta de Windows al cambiar entre una imagen raw a qcow o al revés? ¿Seguirá detectando cambio de software?
La lógica nos dice que no debiera ser, ya que el "hardware" virtual está condicionado por qemu, y no debiera cambiar. Para asegurarme, hice una prueba. Transforme una imagen raw que funcionaba correctamente a formato qcow

Luego generé una nueva máquina con la imagen nueva

Sin olvidarse de configurar correctamente el nuevo formato qcowen el disco virtual

Y el resultado fue el esperado; funcionamiento perfecto.

Solo quedaba por comprobar que también funcionaran correctamente al copiar las imágenes en ordenadores diferentes. He copiado las imágenes y las he utilizado en un ordenador muy diferente (AMD-Intel; placa ASUS-placa INTEL...) con una instalación similar de Fedora 18 y virt-manager. Las imágenes funcionan perfectamente.
Adiós VirtualBox, aunque de hecho ya no lo usaba salvo necesidades de trabajo especiales (algoritmo CHAID que no está desarrollado en ningún paquete de R).

De VirtualBox a virt-manager. Episodio 2. De pantallazo azul a un arranque correcto

En la entrada anterior habíamos dejado una máquina virtual con un disco virtual de Windows XP convertido desde vdi a img o qcow en un pantallazo azul continuo. Pero como decíamos al final, esto tiene solución. Simplemente debemos reparar la instalación de Windows. Necesitamos una ISO de Windows XP (seguro que con un CD también funciona, pero no lo he probado).
Partimos desde virt-manager y generamos una nueva máquina virtual, pero en vez de importar imagen de disco externo pedimos un medio de instalación local, como si fueramos ha hacer un disco virtual nuevo.

Le indicamos dónde está la ISO de Windows XP,

y luego decidimos como antes cuanta RAM dedicamos a la máquina virtual, y no nos olvidemos en la configuración de indicar que el almacenamiento tiene el formato qcow (de ser así; si es raw, no hace falta). En la etapa 4 de la creación, al habilitar el almacenamiento escogemos uno ya existente, donde indicamos nuestro disco convertido (img o qcow)

El sistema arrancará en la ISO de Windows y seguimos todos los pasos como si fueramos a instalarlo. NUNCA seleccionar la primera reparación, ya que eso nos dejaría en un terminal sin comandos adecuados para lo que queremos.

Seguimos la instalación hasta que se detecte la instalación de Windows que ya está en el disco virtual. Ahí pedimos la reparación.

En el caso de que no nos detecte Windows instalado y nos diga que la partición está vacía, probablemente estamos en un dosco con formato qcow y no se lo hemos indicado a virt-manager, y qemu no es capaz de leer. Cancelamos y volvemos hacia la configuración de la máquina virtual. Una vez pedida la reparación, Windows comienza una instalación, pide el número (se requiere una licencia de Windows para usarlo, aunque sea en una máquina virtual), etc...

En todas las pruebas que he realizado termina correctamente y acaba en una pantalla como para arrancar diciendo espere

Sin embargo he dejado dos ordenadores toda una noche y sigue así por la mañana, así que lo mejor es forzar el apagado de la máquina virtual y arrancarla de nuevo. En todas las pruebas, una con una imagen en bruto img y otra con qcow2 ha arrancado correctamente

y el sistema funciona adecuadamente, conservando la configuración y las aplicaciones.

En resumen. ¿Es necesario hacer todo esto o lo instalamos de nuevo?
Depende. Si en ese disco virtual tenéis aplicaciones o el certificado digital u otras cosas que nos lleve mucho tiempo preparar, ganamos tiempo convirtiendo los discos virtuales existentes para VirtualBox. Si no necesitamos nada de lo anterior, acabamos antes instalando de nuevo en virt-manager o con Box-Cajas.
LA conversión es rápida, dependiendo del volumen del disco, claro. el arreglo lleva el mismo tiempo que una instalación de Windows; nos ahorramos la instalación de todo lo demás.
Espero que haya quedado claro, por si alguien se encuentra en algún momento en un caso parecido al mío.

De VirtualBox a virt-manager. Episodio 1. Conversión y error

Desde hace tiempo no utilizo para nada los programas de Windows, así que solo conservaba en un ordenador imágenes para máquinas virtuales. Sin embargo he necesitado temporalmente una aplicación y he tenido que usar mis viejos ficheros vdi en VirtualBox. El problema estaba en que el ordenador en que los tenía es el menos potente de los que dispongo. Además, hemos dejado de usar todas las aplicaciones de Oracle, y no estaría mal pasar nuestros discos virtuales a virt-manager, que nos permite usar qemu de forma gráfica en Fedora. Vamos a describir el proceso paso a paso:
1. Lo primero que debemos hacer es convertir nuestros discos virtuales a un formato que pueda usar qemu. Podemos hacerlo a una imagen raw o a qcow2 (qemu Copy on write). Podemos usar el propio VirtualBox, si está instalado para convertir una imagen vdi a una imagen en bruto, y luego qemu-img para convertir ésta en qcow2, como podemos ver aquí (tomado de esta página).

Lo podemos hacer así si tenemos instalada VirtualBox. En los ordenadores en que no lo tengamos, no es necesario instalarlo, ya que qemu puede convertir directamente los discos virtuales vdi.

En mi caso estaba probando en varios ordenadores, uno con VirtualBox y otros sin. qemu-img también puede convertir a raw, por supuesto, y he generado en todos los casos imágenes img y qcow2 para hacer diferentes pruebas.

2. Una vez convertidas, solo tenemos que generar nuevas máquinas virtuales con virt-manager. He intentado usar cajas (Box), pero está hecha para instalar máquinas nuevas, o al menos no he encontrado la forma de aplicar discos virtuales existentes. Si no teníamos virt-manager instalado simplemente yum install virt-manager

Y llamamos por terminal o gráficamente a la aplicación. Busca los hipervisores disponibles y suele faltar el demonio de quemu, y pide su instalación al llamar a virt-manager (administrador de máquinas virtuales) por primera vez (con sus dependencias)

Luego, simplemente seguimos los pasos, llamamos a virt-manager, creamos una máquina virtual nueva

Le damos un nombre indicativo, sobre todo si tenemos más discos virtuales con diferentes sistemas y para cosas diferentes y le indicamos la localización del disco virtual que acabamos de convertir

Le indicamos la memoria que le asignamos a esa máquina virtual, en función de la disponible. No debe superar la mitad del sistema, y nunca sobrepasar 3072 para un Windows XP de 32 bits, por que no usará más.

Si la imagen escogida era en bruto, no hace falta más; sin embargo, si es qcow2, es importante marcar Personalizar la configuración,como vemos aquí

para que al pinchar en finalizar nos deje pasar por la configuración antes de arrancar para poder indicar que el disco virtual tiene un formato de almacenamiento qcow, ya que si no dará un error de disco no arrancable, ya que no qemu llega a leer el formato interno

Y todo diría que ya hemos acabado, pero no. Para imágenes de distribuciones de Linux estoy seguro de que no hay más problema y todo funcionará, pero para Windows viene lo peor; el sistema ve un cambio de hardware y simplemente no arranca. Muestra un pantallazo azul (sí, de esos de siempre) y salta a un arranque seguro o normal, pero aunque arranques a prueba de fallos para tratar de cambiar los drivers vuelve a fallar, dejando algo como

Un vídeo representativo con fallo continuo

Pero tranquilos, que tiene solución. Próxima entrada, que haré dentro de un rato, por que me faltan unas imágenes.

OpenSUSE 12.2: segundo intento

Ayer instalé la nueva versión de openSUSE. He decidido probar si puedo instalar fácilmente R (para mi es fundamental para mi trabajo) y si me resulta cómodo. Estoy muy contento con Fedora, pero si se tiene cierta práctica con otras distribuciones se tiene algunas ventajas; se sabe más y está uno preparado para cambiar en caso de urgencia (bugs graves, disponibilidad...) sin tener que sufrir dos o tres días para aprender. Por ahora no ha habido problemas; lo he instalado como imagen a través de virt-manager

y la instalación de R ha sido sencilla, ya que está en los repositorios sin tener que buscar formas "diferentes" de instalación, como me había pasado antes.

A ver si tengo algo de tiempo para probar y me acostumbro.