Lo hice y lo entendí

El blog de Vicente Navarro
27 jul

Montar imágenes de disco vdi de VirtualBox

He estado unos días probando el VirtualBox que viene empaquetado en Ubuntu y mis sensaciones no podrían ser mejores:

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

Pero antes de meternos con ella, es importante en este punto recordar que las imágenes de disco de VirtualBox pueden ser dinámicas: el fichero de imagen va creciendo en disco conforme el espacio va haciendo falta hasta su tamaño máximo, o pueden ser de tamaño fijo: el fichero de imagen tiene desde el principio el tamaño del disco.

Las imágenes de tamaño fijo las vamos a poder montar fácilmente, ya que se trata de imágenes raw con una cabecera adicional de VirtualBox, tal y como leemos en Copying from a VirtualBox drive on Linux.

Recordemos primero la entrada Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco. para ver cómo montar las diferentes particiones de una imagen raw. Supongamos que tenemos un fichero de imagen test.raw que contiene las siguientes particiones (son las mismas que las de la entrada Recuperación de particiones perdidas con gpart):

# sfdisk -d /dev/hdb
# partition table of /dev/hdb
unit: sectors

/dev/hdb1 : start=       63, size=  2015937, Id=83
/dev/hdb2 : start=  2016000, size=   504000, Id= 7
/dev/hdb3 : start=  2520000, size=  1674288, Id= 5
/dev/hdb4 : start=        0, size=        0, Id= 0
/dev/hdb5 : start=  2520063, size=   503937, Id=82
/dev/hdb6 : start=  3024063, size=   503937, Id= b
/dev/hdb7 : start=  3528063, size=   666225, Id=83

Al comando mount tenemos que indicarle que monte la partición que empieza en un sector determinado, de forma que le pasaremos la opción offset con el resultado de multiplicar el start= que aparece en la salida del sfdisk por 512, que es el número de bytes en un sector. Así, para montar la primera partición haríamos:

$ sudo mount -t ext3 -o loop,offset=$(( 63 * 512 )) test.raw /mnt/test/

Para la segunda partición sería:

$ sudo mount -t ntfs-3g -o loop,offset=$(( 2016000 * 512 )) test.raw /mnt/test/

Y para la sexta:

 $ sudo mount -t vfat -o loop,offset=$(( 3024063 * 512 )) test.raw /mnt/test/

Pues bien, como decíamos, una imagen de tamaño fijo de VirtualBox es como una imagen raw pero con una cabecera. Podemos ver algo de la información de esa cabecera con “vditool DUMP“:

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

Dumping VDI image file="test.vdi" into the log file...
Log created: 2008-07-27T07:19:37.135796000Z
Executable: /usr/lib/virtualbox/vditool
Arg[0]: /usr/lib/virtualbox/vditool
Arg[1]: DUMP
Arg[2]: test.vdi
--- Dumping VDI Disk, Images=1
Dumping VDI image "test.vdi" mode=r/o fOpen=1 File=00000004
Header: Version=00010001 Type=2 Flags=0 Size=2147483648
Header: cbBlock=1048576 cbBlockExtra=0 cBlocks=2048 cBlocksAllocated=2048
Header: offBlocks=512 offData=8704
Header: Geometry: C/H/S=4161/16/63 cbSector=512 Mode=3
Header: uuidCreation={73b3db93-040d-4004-4d9e-bd4bbe859762}
Header: uuidModification={e98f014b-a165-4cd4-81bd-aae117d8a4e7}
Header: uuidParent={00000000-0000-0000-0000-000000000000}
Header: uuidParentModification={00000000-0000-0000-0000-000000000000}
Image:  fFlags=00000000 offStartBlocks=512 offStartData=8704
Image:  uBlockMask=000FFFFF uShiftIndex2Offset=20 uShiftOffset2Index=20 offStartBlockData=0
The operation completed successfully!

La línea:

Header: offBlocks=512 offData=8704

es la que más nos interesa, ya que nos indica cuánto ocupa la cabecera y, por tanto, dónde empieza el equivalente a una imagen raw. Así, si convertimos la imagen a raw con el comando “vditool COPYDD“:

$ vditool COPYDD test.vdi test-vditool.raw
vditool    Copyright (c) 2004-2008 innotek GmbH.

Copying VDI image file="test.vdi" to DD file="test-vditool.raw"...
The operation completed successfully!

y por otro lado, usando el comando dd y la opción skip (nos saltamos 17 sectores del principio, que son 8704 bytes, el offset de la variable offData) le quitamos la cabecera:

 $ dd skip=17 bs=512 if=test.vdi of=test-dd.raw
4194304+0 records in
4194304+0 records out
2147483648 bytes (2.1 GB) copied, 69.6683 s, 30.8 MB/s

podremos comprobar que ambos ficheros son exactamente iguales, demostrando de esta forma que las imágenes de tamaño fijo de VirtualBox son imágenes raw con una cabecera:

$ md5sum test-vditool.raw test-dd.raw 
b20752a4bb73d3d8bddc007225bd0646  test-vditool.raw
b20752a4bb73d3d8bddc007225bd0646  test-dd.raw

Por tanto, es trivial montar imágenes vdi de ancho fijo. Tenemos que partir de los comandos mount que hemos probado antes con la imagen raw y añadirles el offset que nos muestra el comando “vditool DUMP“. Así, la primera partición la montaríamos de esta forma:

$ sudo mount -t ext3 -o loop,offset=$(( 8704 + 63 * 512 )) test.raw /mnt/test/

La segunda así:

$ sudo mount -t ntfs-3g -o loop,offset=$(( 8704 + 2016000 * 512 )) test.raw /mnt/test/

Y la quinta así:

$ sudo mount -t vfat -o loop,offset=$(( 8704 + 3024063 * 512 )) test.vdi /mnt/test/

Si la imagen es de tamaño variable no vamos a poder hacerlo tan fácilmente, ya que la cabecera, que será mucho más grande, contendrá la situación de cada bloque usado del disco en el fichero de imagen, algo que ya no permite un montaje directo loop como antes.

Sin embargo, lo que sí que podemos hacer es convertir esa imagen de tamaño variable a una imagen raw y luego, al convertirla de nuevo a vdi se convierte en una imagen de tamaño fijo. Por ejemplo, partimos de una imagen vdi de Windows XP de tamaño variable:

$ ll WindowsXP.vdi 
-rw------- 1 vicente vicente 1534108160 2008-07-26 11:45 WindowsXP.vdi

La copiamos a una imagen raw:

$ vditool COPYDD WindowsXP.vdi WindowsXw.raw
vditool    Copyright (c) 2004-2008 innotek GmbH.

Copying VDI image file="WindowsXP.vdi" to DD file="WindowsXP.raw"...
The operation completed successfully!

y comprobamos que usa el tamaño máximo especificado al crearla (10 GiB en este caso):

$ ll WindowsXP.raw WindowsXP.vdi
-rw------- 1 vicente vicente 10737418240 2008-07-27 09:42 WindowsXP.raw
-rw------- 1 vicente vicente  1534108160 2008-07-27 09:42 WindowsXP.vdi

la pasamos de nuevo a vdi:

 $ vditool DD WindowsXP-fijo.vdi WindowsXP.raw
vditool    Copyright (c) 2004-2008 innotek GmbH.

Converting VDI: from DD image file="WindowsXP.raw" to file="WindowsXP-fijo.vdi"...
Creating fixed image with size 2147483648 Bytes...
The operation completed successfully!
Writing data...
The operation completed successfully!

y vemos que usa justo 10 GiB más la cabecera (41472 bytes):

$ vditool DUMP WindowsXP-fijo.vdi | grep offData
Header: offBlocks=512 offData=41472

$ echo "10*1024*1024*1024+41472" | bc
10737459712

$ ll WindowsXP.raw WindowsXP.vdi WindowsXP-fijo.vdi 
-rw------- 1 vicente vicente 10737459712 2008-07-27 09:58 WindowsXP-fijo.vdi
-rw------- 1 vicente vicente 10737418240 2008-07-27 09:42 WindowsXP.raw
-rw------- 1 vicente vicente  1534108160 2008-07-27 09:42 WindowsXP.vdi

En este punto, podríamos usar tanto la imagen raw como la vdi de tamaño fijo para montar la imagen por loop tal y como hemos visto unas líneas más arriba.

Además, también podríamos volver a convertir la imagen en tamaño variable con “vditool SHRINK“:

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

Shrinking VDI image file="WindowsXP-fijo.vdi"...
progress: 0%Log created: 2008-07-27T08:03:48.004133000Z
Executable: /usr/lib/virtualbox/vditool
Arg[0]: /usr/lib/virtualbox/vditool
Arg[1]: SHRINK
Arg[2]: WindowsXP-fijo.vdi
Dumping VDI image "WindowsXP-fijo.vdi" mode=r/w fOpen=0 File=00000004
Header: Version=00010001 Type=2 Flags=0 Size=10737418240
Header: cbBlock=1048576 cbBlockExtra=0 cBlocks=10240 cBlocksAllocated=10240
Header: offBlocks=512 offData=41472
Header: Geometry: C/H/S=0/0/0 cbSector=512 Mode=3
Header: uuidCreation={d10fcff3-c202-4f59-4d9f-dc89810c50e6}
Header: uuidModification={fc3d6e89-1f27-42c5-d884-8c7de5172373}
Header: uuidParent={00000000-0000-0000-0000-000000000000}
Header: uuidParentModification={00000000-0000-0000-0000-000000000000}
Image:  fFlags=00000000 offStartBlocks=512 offStartData=41472
Image:  uBlockMask=000FFFFF uShiftIndex2Offset=20 uShiftOffset2Index=20 offStartBlockData=0
...........10%..........20%..........30%..........40%..........50%..........60%..........70%..........80%..........90%..........100%
Dumping VDI image "WindowsXP-fijo.vdi" mode=r/w fOpen=0 File=00000004
Header: Version=00010001 Type=2 Flags=0 Size=10737418240
Header: cbBlock=1048576 cbBlockExtra=0 cBlocks=10240 cBlocksAllocated=1463
Header: offBlocks=512 offData=41472
Header: Geometry: C/H/S=0/0/0 cbSector=512 Mode=3
Header: uuidCreation={d10fcff3-c202-4f59-4d9f-dc89810c50e6}
Header: uuidModification={fc3d6e89-1f27-42c5-d884-8c7de5172373}
Header: uuidParent={00000000-0000-0000-0000-000000000000}
Header: uuidParentModification={00000000-0000-0000-0000-000000000000}
Image:  fFlags=00000000 offStartBlocks=512 offStartData=41472
Image:  uBlockMask=000FFFFF uShiftIndex2Offset=20 uShiftOffset2Index=20 offStartBlockData=0

The operation completed successfully!

Y vemos que, efectivamente, la imagen sólo usa el espacio de disco estrictamente necesario, que es el mismo que el de la imagen original:

$ ll WindowsXP.raw WindowsXP.vdi WindowsXP-fijo.vdi 
-rw------- 1 vicente vicente  1534108160 2008-07-27 10:06 WindowsXP-fijo.vdi
-rw------- 1 vicente vicente 10737418240 2008-07-27 09:42 WindowsXP.raw
-rw------- 1 vicente vicente  1534108160 2008-07-27 09:42 WindowsXP.vdi

pero como los bloques probablemente ahora están ordenados de otra forma, las imágenes no son exactamente iguales:

$ md5sum WindowsXP*vdi
f6e2d8378df657cec36a12e8ea87864f  WindowsXP-fijo.vdi
f15aa9ff4c377e7af0a08529ab9073dd  WindowsXP.vdi

Para finalizar, recordar que la utilidad qemu-img también nos permite hacer cambios de formato de entre los soportados. No está el vdi desafortunadamente, pero como sí que está el vmdk, podemos usar este comando codo con codo con el comando vditool para pasar de vmdk a vdi pasando por el raw como parada intermedia:

$ qemu-img 
qemu-img version 0.9.1, Copyright (c) 2004-2008 Fabrice Bellard
usage: qemu-img command [command options]
QEMU disk image utility

Command syntax:
  create [-e] [-6] [-s] [-b base_image] [-f fmt] filename [size]
  commit [-f fmt] filename
  convert [-c] [-e] [-6] [-s] [-f fmt] filename [filename2 [...]] [-O output_fmt] output_filename
  info [-f fmt] filename

Command parameters:
  'filename' is a disk image filename
  'base_image' is the read-only disk image which is used as base for a copy on
    write image; the copy on write image only stores the modified data
  'fmt' is the disk image format. It is guessed automatically in most cases
  'size' is the disk image size in kilobytes. Optional suffixes 'M' (megabyte)
    and 'G' (gigabyte) are supported
  'output_filename' is the destination disk image filename
  'output_fmt' is the destination format
  '-c' indicates that target image must be compressed (qcow format only)
  '-e' indicates that the target image must be encrypted (qcow format only)
  '-6' indicates that the target image must use compatibility level 6 (vmdk format only)
  '-s' indicates that the target image must use of type SCSI (vmdk format only)

Supported format: parallels qcow2 vvfat vpc bochs dmg cloop vmdk qcow cow host_device raw

:wq

Entradas relacionadas

34 Comentarios a “Montar imágenes de disco vdi de VirtualBox”

  • osk dice:

    Brutal.
    Sin palabras.
    Súperinteresante.
    Vaya peazo post de investigación del más alto nivel.
    Qué envidia (¿sana?) de ver lo que llegas a saber de todos estos temas!
    Otro artículo más que va directo a la impresora para poder tenerlo a mano en más de una vez…

  • osk dice:

    Hola otra vez.
    Que se me había olvidado comentarte que en la página del VirtualBox hay un apartado de documentos de la “comunidad” (supongo que ya lo habrás visto). Digo yo que estaría muy bueno si enviaras este artículo allá porque así la gente tendría acceso a él de una forma más centralizada y tendría mucha más repercusión. Lo malo es que no sé si exigen que sea en inglés.
    Venga, hasta luego otra vez.
    Y muchas gracias!

  • davidp dice:

    Hola

    Probé VirtualBox y me gusta que sea libre y que corra en distintas plataformas, pero la verdad es que después de probar VirtualBox, Qemu, VMWare y KVM, me quedo con éste último.

    VirtualBox está muy bien y tiene un entorno bastante sencillo de manejar (a excepción del problema que comentas de la red), pero cuando la máquina virtual está corriendo, aunque no esté haciendo nada, consume bastante CPU.

    Una máquina virtual de VirtualBox con una instalación limpia de Debian, recién arrancada y simplemente pidiendo el login consume un 20% de CPU de mi PC.

    Una máquina virtual de KVM con una instalación limpia de Debian, recién arrancada y simplemente pidiendo el login consume un 2% de CPU de mi PC.

    La pega de KVM, como decía antes, es que no tiene una interfaz gráfica sencilla para crear y gestionar máquinas virtuales, y que sólo corre en Linux.

  • @osk ¡Pues muchas gracias! Tendré en cuenta lo de la documentación de la comunicdad de VirtualBox, pero vamos que yo diría que esto es algo que ya se sabrá, supongo…

    @davidp Yo no he podido probar el KVM porque éste necesita que el procesador esté preparado para la virtualización por hardware, ya sea con las extensiones AMD-V o Intel VT. El KVM no nos sirve para aquellos que no tenemos un procesador con estas capacidades, y necesitamos otro sistema de virtualización que no necesite apoyo del hardware, como el VirtualBox, el QEMU o el VMware.

    Y precisamente por esto mismo, porque usas el hardware como apoyo, es por lo que te va tan bien el KVM, que yo no he podido probar nunca. ¿Has probado el VirtualBox o el VMware habilitando la vitualización por hardware?

  • davidp dice:

    > ¿Has probado el VirtualBox o el VMware habilitando la vitualización por hardware?

    He probado VirtualBox habilitando la virtualización por hardware y va un poquito mejor que sin habilitarla, pero no es que mejore espectacularmente.

    De hecho, estas pruebas que te comento de una debian corriendo en VirtualBox y en KVM están hechas en la misma máquina, que soporta virtualización por hardware. En VirtualBox no viene habilitado por defecto, y lo tienes que habilitar tú a mano. Lo hice pero ya te digo: no se nota un gran cambio.

  • @davidp Gracias por la información. Pues tal vez es que el KVM le saca mucho mejor provecho a las capacidades de virtualización por hardware que el VirtualBox… En cualquier caso, bueno es saberlo para probar el KVM tan pronto como se ponga a tiro.

  • davidp dice:

    Gracias a ti, que este blog me ha sacado de más de un atasco !! ;-)

  • Miguel dice:

    ¡Hombre Coco, cuánto tiempo hace que no me dejaba caer por aquí! veo que este sitio ha crecido bastante en cuanto a comentarios, aunque sigues manteniendo el nivel de tus artículos. Mi enhorabuena.

    Me alegra que saques este tema, ya que así puedo comentarte una cosa próxima a este tema que hace unos meses me estuvo rondando por la cabeza. ¿Tú te acuerdas que con el vmware se podía crear disquetes virtuales, que luego podías manipular *obscenamente* con programillas como winimage o rawrite, entre otros? Te servía para hacer disquetes arrancables sin tener un disquete físico ni disquetera. Luego podías meterlos en un cd para hacer tu propio utility-cd-homebrew, etcétera. Supongo que se podrá hacer lo mismo con este virtualbox que nunca he tenido ocasión de probar, pero ¿se podrá hacer algo similar con usb’s?

    Es decir, crear una especie de usb arrancable virtual, en el que puedas guardar la configuración de una live distro, como la rediviva slax, pero de forma virtual; para luego, si te apetece, planchar ese sistema de ficheros en un stick usb real. Yo busqué hace tiempo alguna herramienta para hacerlo con vmware, pero no encontré casi nada. Quizá es que no busqué bien, pero me da la impresión de que no es algo que sea posible a día de hoy y tampoco nadie se ha propuesto hacerlo.

    Yo ideé una *solución* a base de segundo disco duro virtual + posterior dd, pero estaría bien que existiera algo más automatizado, como lo de los disquetes.

    Bueno, prometo no volver alejarme demasiado tiempo de este oasis de buen gusto informático. Sitios como el tuyo demuestran que en la blogocosa la humildad y la sencillez es directamente proporcional al conocimiento y la experiencia, y el contrarrecíproco también es válido.

    Salud y aire fresco

  • @Miguel ¡Gracias! El problema de lo que dices es que mientras que los disquetes son todos exactamente iguales, cada memoria USB es de su padre y de su madre en cuanto a características, tamaño, etc. Por eso me parece difícil.

    Sin embargo, ya hay muchas distribuciones que se dejan instalar fácilmente a USB, y como vimos hace tiempo en:

    Sobre el BartPE. Arrancar Windows/BartPE desde una memoria USB.

    o

    Arrancar Knoppix desde una memoria USB usando SYSLINUX

    de alguna forma, es fácil pasar una imagen de Knoppix o de BartPE/Windows a cualquier memoria USB.

  • miguel dice:

    ¡Gracias por tu respuesta, Vicente!

  • Rigolfas dice:

    Hola,

    Bueno, veo que sabéis mucho más de lo que llego a alcanzar manejando Virtualbox. ..

    Veréis, tengo un problema (como decían en la NASA con el agua al cuello) con la imagen del sistema operativo que quiero utilizar, es el Micro XP v0.8, (se trata de un pc antiguo), ¿qué tipo de imagen ( de la carpeta de archivos de este sistema operativo) es la que reconoce Virtualbox, ya que la creada por nero (.nrg) no vale?

    ¿O bien a qué tipo de archivo me recomendáis transformar este sistema operativo, montar la imagen…, qué aplicación es la más adecuada para usar en virtualbox? Lo digo porque, ni Nero, ni Ultraiso, ni CDburn, ni Ashampoo
    han creado archivos de imagen legibles o reconocidos por Virtualbox.

    Muchas gracias por vuestra ayuda

  • davidp dice:

    Rigolfas: Olvídate de que la máquina de VirtualBox es virtual, y piensa en ella como en una máquina “de verdad”.

    ¿Cómo instalarías esa imagen en una máquina de verdad? Pues exactamente igual haces con Virtualbox.

  • Osk dice:

    Yo tengo escrito un pequeñito tutorial de VirtualBox, para los no iniciados. Por si interesa, está aquí:
    http://iespuigcastellar.xeill.net/Members/q2dg/tutorial-de-virtualbox/

  • AlBundy dice:

    Me sumo a las felicitaciones anteriores por tu artículo. Excelente.

    He releído tus explicaciones varias veces, pero no consigo aclararme en una cosa:
    el disco duro que aparece como hdb, que contiene 7 particiones (ext3, NTFS, FAT…), ¿es real o virtual?. O dicho de otra forma, ¿particionaste un disco duro real, instalaste varios sistemas operativos en él de la manera tradicional, hiciste posteriormente un volcado raw de dicho disco duro a un fichero imagen, y consigues ejecutar los SS.OO. de dicho fichero imagen en QEMU y en VirtualBox?.

    O por el contrario, ¿arrancaste VirtualBox, definiste un disco duro virtual, particionaste el disco duro virtual, y lanzaste las instalaciones de los distintos sistemas operativos desde VirtualBox?.

    Es que me descoloca un poco que muestres las particiones contenidas en un fichero imagen ejecutando “sfdisk -d /dev/hdb” ;-D

    PD: hay un minúsculo error tipográfico en la frase:
    “Supongamos que tenemos UNa fichero de imagen test.raw que contiene las siguientes particiones”

  • @Rigolfas Al VirtualBox le puedes decir que use una imagen de CD ISO como si fuera un CD real. Si tu imagen de MicroXP está en formato NRG, puedes convertirla en ISO con alguna herramienta para tal efecto. Por ejemplo, en Debian/Ubuntu veo que puedes usar el nrg2iso.

    @Osk Gracias por mencionar tu tutorial aquí. ¡Resulta muy ilustrativo!

    @AlBundy ¡Gracias! Voy a intentar aclararte las dudas. El disco hdb es virtual, creado desde cero en VirtualBox y en el que he creado las particiones y he copiado ficheros en ellas para probar estos procedimientos. En realidad ninguna de las particiones de hdb tenía un sistema operativo. El sistema operativo, una Debian, estaba en hda, y desde ella, siempre en VirtualBox, hice ese “sfdisk -d /dev/hdb” que te lía. De todas formas, también podría haber hecho un sfdisk al fichero de imagen raw:

     $ sfdisk -d test.raw 
    Warning: extended partition does not start at a cylinder boundary.
    DOS and Linux will interpret the contents differently.
    # partition table of test.raw
    unit: sectors
    
    test.raw1 : start=       63, size=  2015937, Id=83, bootable
    test.raw2 : start=  2016000, size=   504000, Id= 7
    test.raw3 : start=  2520000, size=  1674288, Id= 5
    test.raw4 : start=        0, size=        0, Id= 0
    test.raw5 : start=  2520063, size=   503937, Id=82
    test.raw6 : start=  3024063, size=   503937, Id= b
    test.raw7 : start=  3528063, size=   666225, Id=83

    ¿He conseguido aclararte la duda?

    PD: ¡Gracias por avisarme de la errata! Me molestan mucho, así que muchas gracias por avisarme de ellas.

  • Rigolfas dice:

    A davidp: Gracias, intento olvidar “la virtualidad” pero debe haber otro problema que impide el funcionamiento correcto o el inicio de Virtualbox, seguiré intentándolo.

    A Osk: Gracias, es una pasada el manual, de los mejores que he leído.

    A Super Coco: Gracias por tus consejos, lo probé todo: cambiar el orden de DVD/CD, Hard disk, floppy. También varios formatos de archivo mediante Ultraiso, Ashampoo, Nero, CDburning… Debe ser otro problema más o menos sencillo que he dejado por el momento…

    Tal vez sea que el PC que uso tiene poca RAM… sólo deja libre 117 MB y yo le adjudico a Virtualbox unos 107 MB… Recuerdo que haciendo una prubeba con PC Virtual no me dejó instalarlo por esto precisamente: falta de memoria RAM.

    Bueno, tras unos días volveré al ataque, quizá con otro PC de mayor capacidad.

    SALUD AMIG@S

  • el_salmon dice:

    Yo tambien pienso que Virtualbox es bastante ligero comparado con Vmware. Creo que la combinación Virtualbox + Windows Fundamentals es la mejor opcion para hacer funcionar sin mucha sobrecarga las aplicaciones de Windows que no son emulables al 100% por Wine en Linux.

  • Rigolfas dice:

    @ el_salmon:

    La verdad, he probado varias “máquinas virtuales”, vmware tiene un sistema o forma de configuración-aplicación que resulta menos práctico que Virtualbox, aunque todavía las hay más sencillas, como: Bochs, pero todavía no la he instalado. De momento la mejor es Virtualbox.

    ¿A qué denominas “windows fundamentals” y cuánto ocupa? Me interesa saberlo como alternativa a micro xp.

    Salud amig@s

  • el_Salmon dice:

    Windows Fundamentals for Legacy PCs basicamente es una version de Windows XP capada. Funciona en ordenadores viejos donde Windows XP no lo puede hacer o lo hace muy lento. En algun blog leí que conseguía reducir en 12 segundos el arranque respecto a WinXP sobre VMWare y la verdad ¡es que es cierto!. Para emulación va mucho más rápido.

  • Rigolfas dice:

    Para el_salmon:

    Gracias por la información!! Podría ser la solución alternativa a micro xp; para los que sólo queremos utilizar o instalar un programa en cada máquina virtual. Por cierto, ¿es necesario activarlo y todo eso…?

    Salud amig@s

  • el_Salmon dice:

    No estoy seguro. Creo que es similar a WinXP corporativo, lleva un numero de serie y listo. No conocia ese MicroXP, huele a version pirata. Windows Fundamentals es una version “oficial” de Windows solo que no viene con equipos nuevos.

  • Rigolfas dice:

    Claro…, ahora que se ofrecen gratis las máquinas virtuales, lo lógico es que se puedan instalar sistemas operativos alternativos también gratuitos; porque no creo que haya much@s usuari@s que se compren los originales destinados a un único pc o máquina virtual… ¡menuda ruina!
    La verdad, no sé si micro xp es pirata, pero sí que no es anunciado de forma oficial!! Es una versión recortada del win XP, muy ligero (creo que lo instalan en 4 minutos) y útil para pocos avatares!!

    Salud amig@s

  • Sagman dice:

    Grande super :D . Eres una machine. Esto me servirá por si algun dia me cargo el XP virtualizado que tengo en el sobremesa :)

  • AlBundy dice:

    Duda solucionada perfectamente :-D

    Muchas gracias, Super Coco.

  • esandov dice:

    Tengo una maquina corriendo UNIX V (tiene mas años que yo), se esta muriendo y no tenemos mas solucion que virtualizar, me pueden ayudar indicandome el proceso para sacar la imagen de este dinosaurio y dejarla corriendo en Virtualbox. ufffff gracias de antemano super

  • @esandov Pues podrías hacerle un dd al disco de esa máquina y luego convertirla a vdi con vditool. Para hacer el dd, podrías sacar el disco de la máquina y ponerlo en otra donde tengas facilidades para hacerlo.

    De todas formas, no sé yo si el UNIX V funcionará en VirtualBox o similares. Yo hace tiempo intenté instalar un ATT UNIX (no sé qué versión sería) y no conseguía arrancarlo en virtualizadores. En cambio, sobre la máquina real sí que funcionaba. Tienes que tener en cuenta que el VirtualBox, VMWare, etc. los prueban con sistemas relativamente recientes, como MS-DOS, Linux, *BSD, etc.

  • eugenio dice:

    Simplemente perfecto, y perfectamente explicado.
    Montar las particiones en el loop era imprescindible para mi para hacer las copias de seguridad con el rsync de la maquina virtualizada. Asi solo se copian los cambios producidos.

    El mejor documento existente hoy dia sobre este tema, gracias

  • @eugenio ¡Muchas gracias!

  • jcasa dice:

    Excelente artículo y que te habrá supuesto mucho tiempo de investigación. También es interesante saber que si montar la máquina virtual es un requerimiento, es mucho mejor crearla ya inicialmente como de tamaño fijo.
    Un saludo,

  • @jcasa ¡Gracias! La verdad es que sí que me llevó algo de tiempo ;-)

  • danidiv dice:

    Excelente el tema yo uso virtualbox en kubuntu 8.10 y virtualizo un Xp, tengo dos discos uno primario master y el otro primario esclavo ,pero Xp me muestra solo el primario master como se hace para que xp muestre los “dos” discos.

    Muchas Gracias

  • @danidiv Mira si te aparece ese disco secundario en el administrador de discos de Windows para que le puedas crear particiones o asignarles letras de unidad a las ya existentes.

  • Toni dice:

    Hola Super,

    estoy intentando montar en casa sobre un Pentium D una maquina sobre la que montar VitualBox para ir jugando con diferente sw de pruebas que me van dejando, relacionado con el montaje de paginas web. La idea es poder tener entornos de pre-produccion en casa, donde probar y despues poder ir a otros servidores a montar los sistemas.

    En este momento tengo montado OpenSolaris 10.8, y sobre él VirtualBox. Crees que es mejor que me pase a Ubuntu, o siendo OpenSolaris de la misma SUN serà más estable lo que tengo ahora.

    gracias

  • @Toni Pues me temo que no tengo suficiente experiencia con VirtualBox sobre Solaris, de modo que no te puedo aconsejar…

Tema LHYLE09, creado por Vicente Navarro