El manual de VirtualBox denomina a esta forma de configurar la red entre el guest y el host Host Interface Networking (HIF). En su sección “6.8 Host Interface Networking and bridging on Linux hosts“, “6.8.1.1 Debian and Ubuntu hosts“, el manual nos detalla cómo conseguir configurar el sistema host para que el sistema guest pueda acceder a sus interfaces. Básicamente, los comandos que nos propone ejecutar en el host son:

1. sudo apt-get install bridge-utils

2. Añadir al fichero /etc/network/interfaces:

auto br0
   iface br0 inet dhcp
   bridge_ports eth0

3. sudo /etc/init.d/networking restart

4. sudo VBoxAddIF vbox0 <user> br0

Bueno, pues haciendo eso, lo que conseguiremos será perder la conectividad en el host y no tendremos red ni en el sistema real ni en el virtual.

Como sí que nos explica bien el manual de Ubuntu de VirtualBox en su sección de networking, sólo falta un detalle para que todo funcione bien, y es especificar que el interfaz real del sistema host lo pongamos a manual en el fichero /etc/network/interfaces, no a automático, que es lo que normalmente se tiene por defecto:

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
   bridge_ports eth0

Haciendo esto, sí que nos funcionará bien la red en el sistema real y en el virtual.

Pero, ¿de qué va todo esto? ¿Qué es el interfaz br0? ¿Y en qué consiste el interfaz vbox0?

(...)

Leer el resto de Host Interface Networking en VirtualBox sobre Debian/Ubuntu (1,151 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 16 comentarios
Etiquetas: Debian, GNU/Linux, QEMU, Ubuntu, VirtualBox

Feed enhanced by Better Feed from Ozh

La imagen que creamos allí era, por defecto, de tamaño fijo (no dinámico), de modo que ocupaba en el disco duro el mismo espacio del que disponía la memoria USB, en mi caso 8 GB (que no 8 GiB):

-rwxr-xr-x  1 root    root    8000004096 2008-09-26 23:41 imagen_mem_usb.img*
-rw-------  1 vicente vicente 8000666112 2008-10-05 18:57 imagen_mem_usb.vdi*

Como vimos en Montar imágenes de disco vdi de VirtualBox, podemos convertir dicha imagen de tamaño fijo en una de tamaño dinámico y además, eliminando los bloques no usados, con “vditool SHRINK“:

$ vditool SHRINK imagen_mem_usb.vdi
vditool    Copyright (c) 2004-2008 innotek GmbH.

Shrinking VDI image file="imagen_mem_usb.vdi"...
progress: 0%Log created: 2008-09-27T12:19:10.484950000Z
Executable: /usr/lib/virtualbox/vditool
Arg[0]: /usr/lib/virtualbox/vditool
Arg[1]: SHRINK
Arg[2]: imagen_mem_usb.vdi
Dumping VDI image "imagen_mem_usb.vdi" mode=r/w fOpen=0 File=00000004
Header: Version=00010001 Type=2 Flags=0 Size=8000004096
Header: cbBlock=1048576 cbBlockExtra=0 cBlocks=7630 cBlocksAllocated=7630
Header: offBlocks=512 offData=31232
Header: Geometry: C/H/S=15501/16/63 cbSector=512 Mode=2
Header: uuidCreation={53bea69e-c21b-4273-be9e-df3fa8f1ffd7}
Header: uuidModification={7a7be4b9-188a-42b2-298e-07eaa266a651}
Header: uuidParent={00000000-0000-0000-0000-000000000000}
Header: uuidParentModification={00000000-0000-0000-0000-000000000000}
Image:  fFlags=00000000 offStartBlocks=512 offStartData=31232
Image:  uBlockMask=000FFFFF uShiftIndex2Offset=20 uShiftOffset2Index=20 offStartBlockData=0
...........10%..........20%..........30%..........40%..........50%
..........60%..........70%..........80%..........90%..........100%
Dumping VDI image "imagen_mem_usb.vdi" mode=r/w fOpen=0 File=00000004
Header: Version=00010001 Type=2 Flags=0 Size=8000004096
Header: cbBlock=1048576 cbBlockExtra=0 cBlocks=7630 cBlocksAllocated=7621
Header: offBlocks=512 offData=31232
Header: Geometry: C/H/S=15501/16/63 cbSector=512 Mode=2
Header: uuidCreation={53bea69e-c21b-4273-be9e-df3fa8f1ffd7}
Header: uuidModification={7a7be4b9-188a-42b2-298e-07eaa266a651}
Header: uuidParent={00000000-0000-0000-0000-000000000000}
Header: uuidParentModification={00000000-0000-0000-0000-000000000000}
Image:  fFlags=00000000 offStartBlocks=512 offStartData=31232
Image:  uBlockMask=000FFFFF uShiftIndex2Offset=20 uShiftOffset2Index=20 offStartBlockData=0

The operation completed successfully!

Sin embargo, en este caso no conseguimos apenas ningún ahorro de espacio:

-rwxr-xr-x  1 root    root    8000004096 2008-09-26 23:41 imagen_mem_usb.img*
-rw-------  1 vicente vicente 7993326080 2008-09-30 21:04 imagen_mem_usb.vdi*

La imagen compactada es tan sólo 8000666112-7993326080=7340032 bytes más pequeña que la anterior. Esto es debido a que el proceso de compactación de vditool sólo es capaz de ahorrarnos los bloques que contengan íntegramente ceros, y en el caso de mi memoria USB, fruto de innumerables movimientos de ficheros, ya vemos que son muy pocos los bloques que continuaban conteniendo exclusivamente ceros. Es bien sabido que cuando borramos un fichero, su contenido sigue estando íntegramente en el disco y sólo anotamos en las estructuras del sistema de ficheros que ese espacio que antes usaba tal fichero, ahora está disponible para cualquier otro fichero. Y eso es en lo que se basan los programas de recuperación de ficheros eliminados para hacer su trabajo con mayor o menor éxito según sea el sistema de ficheros y según las operaciones de ficheros que se hayan realizado desde el borrado.

Por tanto, normalmente las imágenes de disco que hayan tenido mucho trajín de archivos y que no tengan mucho espacio sobrante, tendrán pocos bloques que puedan ser eliminados durante la compactación, ya que esos bloques es muy posible que contengan restos de ficheros ya eliminados y no contengan solo ceros.

(...)

Leer el resto de Compactar imágenes de disco de VirtualBox: vditool vs VBoxManage (1,061 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 2 comentarios
Etiquetas: dd, GNU/Linux, VirtualBox, Windows

Feed enhanced by Better Feed from Ozh

Haz el cambio → Reinicia → Comprueba si funciona → Vuelve a arrancar normal

se repite una y otra vez…

Siempre he pensado que sería muy útil poder arrancar esa memoria USB desde una herramienta de virtualización como VirtualBox o VMWare para poder hacer allí tranquilamente las pruebas. Sin embargo, aunque VWMWare permite el acceso a dispositivos USB, si no me equivoco, no permite arrancar desde ellos. El VirtualBox-OSE (la versión GPL), directamente no permite el acceso a dispositivos USB. El VirtualBox normal sí lo permite pero el arranque de un dispositivo USB no es una opción del menú de arranque de su BIOS.

Otra solución sería permitir acceso directo al disco USB /dev/sdX desde el entorno de virtualización. Como el VirtualBox lo trataría como un disco normal, no podríamos simular los problemas que a menudo tienen las BIOS y los sectores de arranque con el hecho de que el disco sea USB, pero al menos podríamos comprobar que, al menos todo parece ir bien. En VirtualBox, la forma de dar acceso a un disco físico es ésta:

VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk -rawdisk /dev/sda

consistente en crear un fichero vmdk enlazado a un disco físico. Sin embargo, la versión 1.5.6 de VirtualBox-OSE, la que lleva Ubuntu Hardy, no incluye este comando. En Debian Lenny, la versión de VirtualBox-OSE incluida, la 1.6.2, sí que lleva el “createrawvmdk“ y funciona bien. Si queremos poder tener acceso directo a discos en Ubunty Hardy, podemos descargar la versión completa (y cerrada) de VirtualBox, que además de incluir características que no lleva la OSE (VirtualBox Editions), está compilado y empaquetado para la mayoría de las distribuciones más conocidas, incluyendo los módulos del kernel necesarios. Por supuesto, no podemos hacer esto por defecto con los permisos de un usuario normal, ya que no podrá acceder a un fichero de dispositivo /dev/sdX directamente ni para hacer el createrawvmdk ni para luego arrancar el sistema dentro de VirtualBox. Tendremos que usar root o ajustar los permisos.

(...)

Leer el resto de Probar en VirtualBox una memoria USB de arranque (724 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 4 comentarios
Etiquetas: dd, GNU/Linux, memorias USB, particiones, VirtualBox

Feed enhanced by Better Feed from Ozh

• Es software libre, a diferencia del VMWare
• Es muchísimo más rápido que el QEMU
• Es mucho más estable que el KQEMU

Sin embargo, respecto al VMware tiene algunas desventajas como que la creación de interfaces de red no es tan sencilla, sino que requiere acudir al manual y hacer algunas operaciones en la línea de comandos. Además, el formato de sus imágenes nativas de disco, el vdi, no es tan estándar/común como el vmdk o el formato raw que puede usar QEMU y que es sólo una copia directa bit a bit de un disco duro.

Respecto a estas imágenes vdi, he estado investigando si se pueden montar directamente como dispositivo loop. Para montar imágenes de VMware podemos usar el VMware DiskMount, una utilidad que incluye el comando vmware-mount. Para montar imágenes raw de QEMU podemos seguir el procedimiento que vimos en: Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco. ¿Se puede hacer algo parecido con las imágenes vdi?

Pues sí que es posible hacer operaciones similares gracias a la utilidad de VirtualBox vditool:

$ vditool
vditool    Copyright (c) 2004-2008 innotek GmbH.

Usage:   vditool <Command> [Params]
Commands and params:
    NEW Filename Mbytes          - create new image;
    DD  Filename DDFilename      - create new image from DD format image;
    CONVERT Filename             - convert VDI image from old format;
    DUMP Filename                - debug dump;
    RESETGEO Filename            - reset geometry information;
    COPY FromImage ToImage       - make image copy;
    COPYDD FromImage DDFilename  - make a DD copy of the image;
    SHRINK Filename              - optimize (reduce) VDI image size.

(...)

Leer el resto de Montar imágenes de disco vdi de VirtualBox (1,431 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 34 comentarios
Etiquetas: GNU/Linux, particiones, QEMU, VirtualBox, VMWare

Feed enhanced by Better Feed from Ozh

Sin embargo, suele ser necesario tener el kernel recompilado para añadir drivers no oficiales, parches y todas esas aplicaciones que necesitan compilarse un módulo del kernel para trabajar, y estoy pensando, por ejemplo, en el parche del bootsplash, en el driver binario de NVidia, en el kqemu, en los módulos del VMWare, en el driver para mi WebCam o para mi tarjeta WiFi.

Pues bien, hace poco tuve que pasar del kernel 2.6.19 al 2.6.20.6 tras una amable sugerencia de mi querido NTFS-3G al que yo no osé contradecir:

Why do I get “WARNING: Deficient FUSE kernel module detected”?

The FUSE technology used by ntfs-3g consists of two major parts: a library and a Linux kernel driver. The message means that you either have the faulty FUSE 2.6.2 release, or the library (FUSE package) is safe but the kernel driver is not. When you install or upgrade the FUSE package then it installs only the library, not the kernel driver. In other words, ntfs-3g and FUSE is safe but not your kernel.

Solution: Please ask your distribution developers to fix the Linux kernel problem. The Linux kernel must be upgraded either to at least version 2.6.20, or the FUSE kernel driver must be upgraded to a safe version which is also included in the FUSE package for Linux kernel version 2.6.9 and later.

(...)

Leer el resto de Cómo solucionar incompatibilidades entre una versión de VMWare y un kernel más reciente (477 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 6 comentarios
Etiquetas: Debian, Kernel, NTFS-3G, QEMU, VMWare

Feed enhanced by Better Feed from Ozh

El Qemu emula diferentes plataformas sobre diferentes sistemas operativos. Si usamos el KQemu, recientemente liberado como GPL, el emulador pasa a usar virtualización y la velocidad del sistema operativo “virtualizado” está en el orden de la que obtendríamos con, por ejemplo, VMWare. VMWare es más maduro y estable pero el Qemu tiene muchas opciones con las que jugar fácilmente.

Pues bien, el Qemu soporta varios tipos de formato de imágenes del disco duro. Una de ellas es la “raw”, que es como si fuera un dd completo de un disco físico. Para montar una imagen “raw” del qemu se puede usar el siguiente comando:

mount -o loop,offset=32256 imagen_disco /path/punto_montaje

Está claro que lo que hace el comando es buscar el sitio dónde empieza la primera partición para usar la imagen como si se tratara de una “imagen de la partición”, no una “imagen del disco”, pero ¿por qué 32256? ¿tanto espacio hay libre antes de la primera partición? ¿casi 32Kb?

(...)

Leer el resto de Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco. (962 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: dd, GNU/Linux, GRUB, particiones, PC, QEMU

Feed enhanced by Better Feed from Ozh