Instalar una máquina virtual con Windows XP con KVM

Otra entrada mientras sigo intentando enterarme de eso de OpenCL. Ya me he tragado 6 horacas de podcast con bastante poco código, a ver si para la semana que viene se puede tener algo medianamente listo. (^_^)

A lo que vamos, que si no no terminamos nunca.

Ayer se me planteó la necesidad de utilizar un sistema de "usar y tirar" para probar un par de chapucillas sin dejar rastro en mi sistema. Y para hacerlo, nada más sencillo que una máquina virtual, la montas, haces lo que sea, y la tiras a la papelera. Sencillo, fácil y divertido. Por problemas de compatibilidad con las chapucillas, necesitaba que mi sistema fuese un Windows, así que conseguí una copia de Windows XP y me dediqué, durante varias horillas a echarla a andar utilizando KVM.

Por supuesto, y esperando que a nadie le pase lo mismo que a mí... drivers del demonio, os explicaré de forma fácil y sencilla cómo se debe/puede montar una máquina virtual con Windows utilizando KVM.

Necesitaremos los siguientes ingredientes:

• Los paquetes qemu y libvirt instalados en nuestro equipo. Desde hace un tiempo kvm está integrado en qemu así que no hay problema por esa parte.
• Un disco/una iso de Windows XP.
• Los drivers de virtio para Windows. Con estos drivers podremos utilizar los dispositivos "virtio", que deberían tener un rendimiento mucho mejor que otras opciones como son virtualizar un hardware concreto.
  Se pueden conseguir de aquí: Virtio-win (el archivo se llama virtio-win-0.1-65.iso)
• Un par de guantes. Con esto podremos evitar tocar todo lo relacionado con Windows, aunque sea en una máquina virtual, si nos da grima.

Muy bien, ya estamos listos para empezar. Si no sabéis si podéis utilizar KVM para virtualizar un sistema, basta con que ejecutéis el siguiente comando:

 grep -E "(vmx|svm)" /proc/cpuinfo

Si no devuelve nada, me temo que no podréis utilizar KVM, lo siento, no tendréis el mismo rendimiento.

Pero sigamos adelante. Una vez que ya tenemos todo lo necesario, tendremos que crear un disco donde vayamos a colocar nuestra máquina virtual. Para ello, vamos a nuestro directorio de trabajo y utilizamos qemu-img create para eso... ¡crear! 

qemu-img create -f qcow2 windoze.qcow2 10G

Con esto, le digo que me cree una imagen de tipo "qcow2" de tamaño 10G que se llame windoze.qcow2. Y aquí será donde trabajaremos. Ahora viene la parte en la que es recomendable ponerse guantes, ya que empezaremos a tocar Windows.

Lo primero será instalar nuestro sistema en su sitio, para ello, utilizamos el siguiente comando:

qemu-system-x86_64 -enable-kvm -cpu host -m 512 windoze.qcow2 -cdrom

Mini-explicación: -enable-kvm: queremos kvm, ¿no?; -cpu host: utiliza todas las extensiones que puedas y que soporte mi cpu; -m 512: asigna 512 MB de memoria RAM para la máquina virtual; y --cdrom : en la unidad de cdrom coloca el disco de windows, que es lo que queremos instalar.

Y ahora a instalar... supongo que todos sabemos instalar Windows, ¿no? Siguiente, siguiente, siguiente, (acepta usted vender su alma al diablo) aceptar. Lo único, sí que hay un punto que le suele costar bastante y es el de "Installing Devices", de hecho, lo dejé una hora y no había avanzado nada... luego reinicié la instalación un par de veces y terminó... Así que no os preocupéis, insistid que se instala.

Una vez hayamos terminado, vamos a hacer lo primero que se tiene que hacer en todo sistema Windows: descargarnos un navegador de verdad para no tener que utilizar nunca jamás de los jamases el internet explorer. Probamos a abrir el explorer y... no hay interneeeeeeee..... eeeee....

¡No desesperemos! Al menos todavía. Lo que pasa es que Windows no nos reconoce el controlador de red que está emulando qemu y por eso no tiene ni idea de como conectarse a la red.

Ahora tenemos dos alternativas, si tenemos mucha prisa por usar internet y no nos importa tener un peor rendimiento, podemos emular una tarjeta de red normalita para que no se queje y arreando. Si escogemos esto, la solución es ejecutar la máquina virtual con este comando:

qemu-system-x86_64 -enable-kvm -cpu host -m 512 windoze.qcow2 -net nic,model=rtl8139 -net user

Si ya que hemos llegado hasta aquí, queremos ir con todo el equipo, y utilizar virtio para obtener mejor rendimiento, ejecutaremos la máquina virtual con este otro comando:

qemu-system-x86_64 -enable-kvm -cpu host -m 512 windoze.qcow2 -net nic,model=virtio -net user

Al arrancar nos dirá que ha encontrado nuevo hardware. Claro, es como si le hubiésemos cambiado la tarjeta de red, pero sigue sin tener ni idea de cómo utilizarla... Por supuesto, Windows es muy listo y propone conectarse a internet para buscar drivers de la tarjeta que le permitiría conectarse a internet, ya sabes "¿Quiere buscar en internet ayuda sobre cómo conectarse a internet?" Todo muy lógico

Pero claro, no nos habríamos bajado un montón de drivers solo por tenerlos de adorno, ¿no? Apagamos y volvemos a arrancar la máquina virtual, esta vez diciéndole que ponga en el cd-rom el disco de drivers que habíamos creado.

qemu-system-x86_64 -enable-kvm -cpu host -m 512 windoze.qcow2 -net nic,model=virtio -net user -cdrom

 Vale, esta vez va la vencida. Vamos al administrador de dispositivos, buscamos la controladora ethernet que no reconoce (Red Hat VirtIO Ethernet Adapter) y le pedimos que reinstale los drivers. Y... ahora mágicamente encuentra algo que puede utilizar como drivers. ¡Estamos salvados! ¡Interneeeeeee! ¿Eh? ¿Qué? ¿Cómo que drivers corruptos?

Este es otro de los momentos en los que Windows demuestra su "infinita sapiencia" y que puede dar más de un quebradero de cabeza. Resulta que en el disco de drivers los hay para diversos sistemas Windows. Pero XP, que es más chulo que nadie pilla el primero que encuentra, que es el de Windows8, y por supuesto no funciona ni nada. Y su solución es decir que están corruptos... porque ya se sabe, si no es lo que quiero entonces está mal hecho.

La solución es coger la carpeta "XP" del cd y dejarla en el disco C. Luego pedimos que expulse el cd para que deje de dar la tabarra. El siguiente paso es decirle a Windows que es idiota y que queremos elegir nosotros a mano el driver. Para ello intentamos reinstalar el driver, pero seleccionamos la opción de "Instalar de una localización específica" y luego "No busques, yo lo elijo" En la ventanita que nos sale escogemos "Tengo disco" y buscamos la carpeta que hemos copiado antes, aquí tendremos dos carpetas, escogemos "X86", seleccionamos el archivo que hay dentro y "Abrir". Ahora ya es siguiente, siguiente, siguiente hasta que lo instale.

Vamos al navegador y voilá de ese, ya tenemos internet. Ya podemos hacer lo que sea que queramos hacer con el entorno virtual antes de tirarlo a la papelera.

Espero que os haya sido útil y os evite estar una hora de "prueba y error" con la red.

Más información:

- KVM 

- QEMU

Esquema de una Raspberry Pi en Arrow

Entrada relámpago mientras sigo investigando lo que es y cómo funciona OpenCL (^_^)

Supongo que la mayoría conoceréis la serie Arrow, esa del arquero verde justiciero que, cual Robin Hood moderno, se dedica a intentar arreglar todos los desaguisados de su ciudad. Aunque sin la parte de robar a los ricos para dársela a los pobres, porque el es rico... y sin la de sus alegres hombres, porque solo tiene dos compañeros... Dejémoslo entonces en que es un arquero justiciero que se dedica a intentar arreglar todo lo que está mal en su ciudad.

El caso es que en el episodio de ayer necesitaban rastrear un envío de armas pero, oh, desastre de los desastres, la baliza encargada de enviar periódicamente una señal de rastreo está desactivada. Afortunadamente, la genial geek/hacker/informática experta (y usuaria de windows, pero no se puede ser perfecto ni en una serie XD ) encuentra un fallo en el hardware que permite activarlo a distancia.

Durante esta explicación se puede ver un esquema de la baliza en cuestión.

 

No sé si os recordará a algo. ¿Una plaquita pequeñaja de menos de 50$ con un core ARM a la que se le puede instalar linux? ¿Sí, no? Vamos a ver si se parece a la plaquita de esta foto.

 

 

¿Mejor así? ¿Se parecen? Pues ahí lo tenéis, una raspberry pi apareciendo en Arrow.

Y ahora a seguir investigando.

Obtener soporte de OpenCL en Drivers Mesa usando Arch

[AVISO IMPORTANTE] No sé qué leches habrá pasado pero la última versión del paquete opencl-mesa-git rompe el soporte de OpenCL así que NO actualicéis más de la versión 59136. Al parecer, en la siguiente versión el nombre de la librería ha cambiado de libOpenCL.so a libMesaOpenCL.so y ahora se queja de mala manera. Cuando el problema esté resuelto lo avisaré sin falta. [FIN DEL AVISO]

[ACTUALIZACIÓN] Ya se puede volver a utilizar perfectamente el paquete opencl-mesa-git del repositorio dado. Resulta que en mesa habían cambiado al modelo de ICD para poder tener diferentes implementaciones de OpenCL a la vez instaladas y por eso ahora el paquete se llamaba libMesaOpenCL.so. Pero el mantenedor del repositorio se había olvidado de modificar el PKGBUILD para añadir la dependencia de libcl, que es el cargador de ICD. Me puse en contacto con él y los paquetes ya están arreglados y funcionan.

Notad que ahora ya no proveen los headers de OpenCL, así que si queremos compilar código de OpenCL necesitaremos instalar también opencl-headers. Si no lo hacemos, tendremos que comprobar el soporte de OpenCL con alguna aplicación que sepamos que lo utiliza.

Notad también que el PKGBUILD que aparece en el repositorio todavía (28/10/13) no es el actualizado. [FIN DE LA ACTUALIZACIÓN]

Tanto en nuestras casas como en nuestras aulas u oficinas, utilizar un mobiliario de calidad y confortable es básico para poder trabajar de la mejor forma posible. Así pues, ¿Qué hacemos con, por ejemplo, una mesa que nos sea incómoda? La tiramos y la cambiamos:

La tiramos (╯°□°）╯︵ ┻━┻
Y la cambiamos ┬─┬ノ( ゜-゜ノ)

Pues precisamente vamos a hacer esto mismo con nuestra mesa, la única diferencia es que no será una mesa física, sino que son los drivers mesa los que vamos a cambiar.

Lo que queremos es poder aprovechar, o al menos servir como beta-testers del soporte de OpenCL en tarjetas gráficas AMD con nombres tan simpáticos como "Evergreen" o "Southern Islands". Y además, como regalo nos llevamos el ser beta-testers también de clang y llvm, ¡son todo ventajas!

Al menos esto era lo que yo quería: Probar el soporte de OpenCL en la tarjeta gráfica... por aquello de aprender y tal. Que al menos uno tiene la intención de cumplir todo lo que pueda con sus propósitos de año nuevo.

Bueno, que me lío, al tajo.

Supondremos que tenemos un sistema Arch, actualizado y en un equipo con una tarjeta gráfica adecuada. Si utilizamos abs para echarle un ojo al PKGBUILD de mesa, podremos ver que no tiene la flag de '--enable-opencl'. Por tanto, se nos presentan dos alternativas, la difícl y la fácil.

La difícil sería modificar el PKGBUILD para añadir la flag necesaria , compilar e instalar. ¿Y esto es complicado? Bueno... si solo fuese esto no lo sería, pero aparecen dos problemas. El primero es que se necesita el paquete libclc para compilar mesa con OpenCL, y ese hay que obtenerlo desde el AUR. Supongamos que resolvemos este pequeño percance y tenemos nuestro flamante paquete listo para ser instalado. ¿Qué podría ir mal ahora? Por ejemplo... conflictos con varios paquetes ya instalados.

Llegados a este punto, uno ya se cansa y quiere mandar a la porra a la pobre mesa, al OpenCL y la tarjeta gráfica, menos mal que siempre queda la salida fácil.

La forma fácil de hacer todo esto consiste en utilizar un repositorio con paquetes ya preparados para ser instalados y preparados para que resuelvan los conflictos ellos solitos.

Para esto, podemos utilizar el repositorio no oficial de mesa-git. Añadimos un par de líneas a nuestro pacman.conf:

[mesa-git]
Server = http://pkgbuild.com/~lcarlier/$repo/$arch

Le pedimos a pacman que actualice sus repositorios:

sudo pacman -Syy

E instalamos opencl-mesa-git

sudo pacman -S opencl-mesa-git

Esperamos a que termine todo, reiniciamos por si acaso y listos. Ahora solo queda comprobar que todo funcione. A esto nos ayudará Tom Stellard, uno de los desarrolladores de mesa y que tiene un pequeño repositorio con tests para OpenCL.

Nos vamos a nuestro directorio de trabajo/frikeo y clonamos su repositorio con git:

git clone http://cgit.freedesktop.org/~tstellar/opencl-example/

Nos movemos al mismo y compilamos todo con make:

cd opencl-example && make

Ahora probamos los tests:

./run_tests.sh

Si al final obtenemos un "71 passes, 0 fails" felicidades, tienes OpenCL instalado y funcionando (al menos experimentalmente) Si no, primero asegúrate de estar utilizando una de las tarjetas soportadas o si no, pon un bug.

Como nota importante: El soporte todavía es experimental e incompleto, tampoco empecéis a decir que X cosa no funciona porque todavía queda mucho trabajo por hacer.

Espero que os haya sido útil, si tenéis algún problema no dudéis en preguntar, ¡quizás hasta os pueda ayudar! En un futuro trataré de hacer algún post sobre OpenCL, explicando lo que es y como hacer pequeños programitas con él.

Más información en: GalliumCompute
Mi hilo en los foros de Arch preguntando esto mismo: Arch Forums

Retomando el Blog, Otra Vez

Hola otra vez, tal vez recordéis que hace tiempo tenía un blog.... y lo abandoné, hasta ahora. Después de un tiempo pensándolo he decidido retomar la labor de escribir por aquí algunas cosillas. Aunque esta vez va a ser con una filosofía más o menos distinta, más bien basada en "publicaré lo que quiera y cuando quiera". Así que os podréis esperar cualquier cosa, como viene siendo habitual, por otra parte, en mi cuenta de Twitter.

Tal vez os estéis preguntando porqué, después de tanto tiempo, he decidido volver a escribir en un blog, de forma que cualquiera me pueda leer, por ejemplo gente que ande aburrida por google. Pues bien, la respuesta es muy simple:

- ESCRIBIR -

Esa es la respuesta, escribir, vuelvo a retomar el blog para escribir. O más bien, para tratar de escribir mejor. He notado que últimamente, más en este último par de años, me cuesta mucho escribir un texto largo sin que sea una sucesión de ideas que caben en un tweet.

Si habéis entendido que vuelvo por aquí porque Twitter está haciendo que mi mente no desarrolle nada más allá de los 140 caracteres habéis acertado. Ya que es lo que creo. El límite de caracteres de Twitter nos hace buscar la compactación máxima de las ideas de forma que podamos expresarlas cada vez en frases más y más cortas. Esto nos hace escribir mal. O mejor dicho, no nos hace necesariamente escribir mal, un texto puede estar compuesto perfectamente de frases de menos de 140 caracteres. Lo que hace es que nos cueste mucho más desarrollar a lo largo de varios párrafos una idea.

Esto es precisamente lo que busco, no ya evitar, ya que he caido, sino corregir. Creo que, regresando a un blog, de forma que puedo escribir artículos más desarrollados, reflexionados y corregidos podré, en alguna medida, volver a poder escribir "parrafadas"

Hasta aquí mis razones, por las que agradecería que fuerais indulgentes conmigo, al menos en los primeros posts, trataré de mejorar con los siguientes.

En cuanto al contenido y frecuencia del blog. No voy a intentar llegar a la frecuencia del Tipo de la Brocha de dos artículos bastante largos a la semana. Tampoco creo que seré capaz de llegar a la calidad y a la capacidad de reflexión de Elisabet Roselló u otros escritores. Más bien, este blog va a contener lo que a mí me apetezca, desde reflexiones personales, comentarios de libros y películas hasta tutoriales/ejemplos sobre alguna cosa relacionada con la tecnología.

Esperemos que en esta nueva etapa, el blog vuelva a funcionar como a mí me gustaría, y yo mismo vuelva a escribir como me gustaría.

P.D: Si a alguien no le gusta algo de la plantilla, puede decirlo, y si sugiere otra y me gusta más pues la pondré, que ahora es fase de pruebas (^_^)