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.

Máquinas virtuales con ficheros vdmk múltiples

Para una prueba que teníamos que realizar un compañero preparó una máquina virtual creada con vmware con Debian 6 . Al intentar probarla, descubrí que kvm no puede manejar imágenes en ficheros múltiples -siempre hay algo nuevo que aprender-, con lo que me estuve planteando diferentes posibilidades, entre las que me parecían más lógicas la conversión de los ficheros vmdk a raw y concatenarlos en uno único (ver aquí). En ese intento, por alguna razón que aun no he podido comprender, el comando qemu-img no se podía ejecutar; en teoría mi distribución no lo encontraba, aunque era bien cierto que estaba instalado y respondía a man qemu-img. Después de algo de frustración realmente pensé que ya que era una máquina que iba a ser ejecutada de forma repetida a través de vmware player, yo mismo debería probarla con ese mismo visor. Además, soy usuario registrado de vmware desde hace muchos años, aunque desde un tiempo acá confío completamente en virt-manager para todo. En resumen, me bajé el último player, y luego simplemente

sh ./VMware-Player-6.0.3-1895310.x86_64.bundle

y listo.

La verdad es que funciona muy bien.

Aun así, fue solo para una comprobación. Para mi uso habitual, seguiré usando virt-manager.

Actualizaciones y virus

Por supuesto, me refiero a las actualizaciones de Windows. Como se puede ver a lo largo de la historia de este blog, he abandonado progresivamente el uso de Windows, pero como no soy ni matemático ni programador, necesito algún algoritmo de SPSS que no soy capaz de programar en R. Por esta sutil razón mantengo máquinas virtuales de Windows, fundamentalmente para hacer CHAID exhaustivo en SPSS. Como es natural, las máquinas de Windows tienen los mismos defectos que Windows solo (de hecho, el SO no "sabe" que está en un fichero dentro de otro sistema) y en él tengo antivirus, software antimalware etc...
Curiosamente, en las últimas actualizaciones de las diferentes máquinas (que son clones de si mismas), Avira detecta en la actualización la presencia de un virus.

En ocasiones lo detecta al empezar la actualización de Explorer 8 (uso un Windows XP en el que instalo lo menos posible) y en otras an actualizarse Windows Defender. El segundo caso es bastante lógico, ya que los antivirus suelen detectar en las bases de datos de otros antivirus los patrones de identificacion de virus, y dan señal de alarma, pero me extraña la detección en Explorer 8. La actualización queda bloqueada en ese momento hasta que se da una orden al antivirus, y luego vuelta a empezar. La verdad, no me preocupa gran cosa, ya que en el caso de que sea verdad y empiece a dar problemas, lo único que tengo que hacer es borrar el fichero y sustituirla por una copia de seguridad que tengo a mano.

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.

Ubuntu 12.04 - nada que declarar

He instalado Ubuntu 12.04 en una máquina virtual usando Virtual Machine Manager para ver si me interesa o no. He intentado usarlo; es más, casi me he forzado, pero estoy tan acostumbrado a Fedora que simplemente, Ubuntu me aburre. Espero ansiosamente Fedora 17 y puedo afirmar que mi interés por Ubuntu ha llegado al cero absoluto.

VirtualBox en Fedora

La instalación es bien sencilla. En vez de instalar la versión OSE disponible en repositorios

es preferible instalar la versión bajada de Oracle, como podemos ver en yumex. Bajaremos 3 ficheros: el binario correspondiente a nuestra distribución, bien la versión para 32 o 64 bits, según corresponda, el vbox extpack y la iso de las guest additions, para luego actualizarlas en los sistemas internos de la máquina virtual.
Una vez instalada, por supuesto nos aparece un error, debido a que VirtualBox no ha sido introducido en el kernel (Linux no está construido como Windows)

Por suerte Linux nos dice lo que debemos hacer, y ejecutamos la orden que nos indica

/etc/init.d/vboxdrv setup

pero nos aparece otro error.

Se debe, como se puede ver, a que DKMS, encargado de generar módulos para el kernel, no está instalado en Fedora 16. Debemos instalarlo primero.

Puede aparecer un tercer error, debido a no disponer de gcc instalado (compilador de varios lenguajes para Linux). Al intentar generar el módulo de VirtualBox en el kernel y llegar a make, comando encargado de decidir que compilar, sin gcc no se puede compilar. Tendríamos en ese caso que instalar gcc también. Ese error, si aparece tras la instalación de dkms, lo tenemos que leer en el log resultante (que nos indica el propio error donde está).

Una vez superados todos estos problemas, ya se genera un módulo para VirtualBox en el kernel

Y así ya podemos instalar el extpack en VirtualBox, arrancar las máquinas y actualizar los guest additions en los sistemas operativos invitados. Perfecto. Ya podemos usar los programas de Windows. Ahora viene la pregunta del millón, ¿para qué?
Por costumbre, aun uso VirtualDub, pero a través de wine y rar en el terminal. Simplemente me queda el uso del escáner, un Canoscan 8000 que Linux no reconoce.

Recuperación en terminal de volúmenes perdidos en compresiones rar multivolumen

Lo prometido es deuda, y un comentario me ha recordado que aun no había mirado la recuperación de volúmenes rar perdidos en el terminal de Linux. No lo había mirado por que cobardemente estaba recuperando los volúmenes en una máquina virtual de Windows con un WinRar shareware sin licencia. Los días de prueba se han terminado, otra razón más para solucionarlo con terminal. En el fondo, es muy sencillo.
Paso 1. Instalación de rar - un simple sudo apt-get install rar

Paso 2. La orden, por si no nos acordamos, la podemos consultar a través de man rar, y entre las opciones, la que nos interesa es la rc

Paso 3.  Como prueba he borrado el paquete 4 de una compresión multivolumen. Para facilitar la acción, he corregido el nombre, lleno de espacios, que en terminal de Linux son siempre un problema, por una simple f. Como se ve en la imagen, falta el volumen 4.

Paso 4. Ejecutamos el comando rar con la opción rc
rar rc f.part01.rar
En el caso de WinRar es necesario llamar a los ficheros rev; en este caso, la opción rc nos permite llamar al multivolumen. El comando calcula los volúmenes, observa el número de volúmenes de recuperación y cuantos paquetes faltan y comienza la reconstrucción

Paso 5. Listo. Todo ha funcionado. Reconstrucción 100% realizada.

Aquí esta el paquete.

Otras dudas:
Si me faltan volúmenes de recuperación, ¿qué puedo hacer? Solo es necesario tener tantos volúmenes de recuperación como paquetes nos falten. Por ejemplo, en este caso he borrado el primer volumen de recuperación y el paquete 14; como le quedan 2 volúmenes de recuperación (2 y 3) puede recuperar perfectamente el que falta.

Como decía antes, en WinRar hacía un doble click en cualquiera de los volúmenes rev y el programa comienza. En el terminal también vale. La orden ha sido

rar rc f.part01.rev

es decir, llamando al primer paquete de recuperación. Como disponemos de tres volúmenes de recuperación, para terminar la prueba, he borrado hasta tres paquetes que el programa debería poder recuperar.

El resultado ha sido perfecto.

Mediante estas opciones en el comando rar nos ahorramos tener que usar una máquina virtual para esto, que solo da más color, a cambio de un consumo increíble de recursos.

Si lo que queremos es hacer la compresión multivolumen, también se puede hacer en el terminal. Para una ayuda más completa que la indicada mediante man rar, puede ser interesante acudir al fichero rar.txt, que está, al menos en esta distribución (Ubuntu 11.10), en el directorio /usr/share/doc/rar comprimido como rar.txt.gz.
Si después de salvar los paquetes tenemos problemas con los caracteres en el terminal (no reconocimiento de ñ o letras acentuadas), como ya había señalado en la otra entrada, se desinstala rar. Si lo necesitamos otra vez, se instala de nuevo; son solo unos segundos.
Sin embargo, no debemos olvidar lo que dice la documentación del paquete (por ejemplo, ver en Synaptic) "This program is shareware and you must register it after 40 days of use.". Es decir, sigue siendo de pago.
Respecto a la pregunta de por que realizo la prueba en un directorio llamado Compartido_VirtualBox, diré que ese es el directorio en mi máquina para el intercambio Linux-Windows, a través de VirtualBox. Pero solo hasta hoy, ya que no preciso WinRar. El único vinculo que queda para mantener VirtualBox y Windows XP es SPSS. Va a ser difícil librarme de él, por que algunas técnicas estadísticas aun no las domino en R y, además, R no dispongo de un paquete que haga CHAID. Tendré que valorar el uso de "tree" en vez de CHAID y comparar resultados.