Cómo usar dispositivos RAW en máquinas virtuales

Cuando trabajas con virtualización avanzada llega un momento en el que las típicas imágenes de disco virtual (VDI, VMDK, QCOW2, etc.) se quedan cortas. Ahí es donde entran en juego los dispositivos RAW asociados directamente a máquinas virtuales, ideales para exprimir el rendimiento del almacenamiento o reutilizar discos y particiones existentes sin tener que copiarlos a otro formato.

Este tipo de configuración se usa mucho en entornos como VirtualBox, VMware y Proxmox, clusters de Oracle RAC o laboratorios forenses, y aunque al principio asusta un poco, si entiendes bien qué estás haciendo puedes sacarle muchísimo partido. A lo largo de este artículo vamos a ver, con calma pero al detalle, cómo usar dispositivos RAW en máquinas virtuales en distintos hipervisores y escenarios reales, qué ventajas ofrecen y qué precauciones debes tener para no liarla con los datos.

Qué es un dispositivo RAW y por qué usarlo en máquinas virtuales

Un dispositivo RAW es básicamente un acceso directo y sin capas intermedias a un disco físico, una partición concreta, un volumen LVM o una LUN presentada desde una cabina SAN. No hablamos de un archivo de disco virtual, sino del propio dispositivo tal y como lo ve el sistema operativo del host.

Cuando se trabaja con discos virtuales normales, el hipervisor almacena los datos en ficheros .vdi, .vmdk, .qcow2, .raw, etc. dentro de un sistema de ficheros (VMFS, ext4, XFS, ZFS, …). Con un dispositivo RAW, en cambio, la VM accede directamente al bloque de almacenamiento subyacente, ya sea una partición local, un volumen LVM, una LUN iSCSI/Fibre Channel u otra unidad de disco completa.

Esta forma de trabajar tiene varias ventajas: menor sobrecarga, acceso casi nativo al hardware y posibilidad de reutilizar discos ya existentes sin tener que convertirlos. En entornos de clúster, además, permite que varias máquinas virtuales vean la misma LUN y gestionen el acceso compartido desde el propio sistema operativo invitado o el software de clúster.

Ahora bien, usar dispositivos RAW no es mágico: implica renunciar (según el modo) a algunas funciones de la capa de virtualización, como ciertas instantáneas o clonados fáciles, y exige mucho más cuidado para no sobrescribir discos equivocados. Por eso es tan importante entender qué hace exactamente cada hipervisor con este tipo de mapeos.

Uso de dispositivos RAW en VirtualBox

VirtualBox, por defecto, crea sus máquinas virtuales en archivos de disco como .vdi o .vmdk; para manejarlo, revisa VirtualBox comandos y ejemplos. Sin embargo, también permite utilizar dispositivos en bruto del host: discos enteros, particiones concretas o volúmenes LVM. Esto es muy útil si quieres que la VM trabaje sobre un disco ya preparado o si necesitas el máximo rendimiento sin pasar por una capa de archivo.

La idea es sencilla: en lugar de crear un disco virtual nuevo, le dices a VirtualBox que “envuelva” un dispositivo físico y lo presente a la máquina virtual como si fuera un disco más. Ese envoltorio se hace mediante un pequeño archivo de descriptor que apunta al dispositivo RAW real (por ejemplo, /dev/sdb o /dev/mapper/vgdatos-lvvm1).

Este enfoque también sirve para casos en los que tienes una instalación previa de un sistema operativo en un disco físico o LVM y quieres arrancarla dentro de una VM de VirtualBox manteniendo la estructura original. O cuando quieres usar una partición concreta para pruebas sin tocar el resto del disco.

Además, con VirtualBox puedes trabajar con formatos RAW de otra manera: usando la herramienta VBoxManage para convertir imágenes de otros hipervisores a RAW. Esto se ve mucho en escenarios de análisis forense, donde interesa tener un volcado tipo dd con todos los bytes del disco original.

Convertir discos VMDK a formato RAW con VBoxManage

Una situación muy habitual es recibir una máquina virtual de VMware en formato VMDK y querer analizar ese disco con herramientas forenses como FTK, Autopsy o similares. En esos casos, suele interesar convertir la imagen a un fichero RAW plano (tipo dd) en lugar de trabajar directamente con el VMDK.

VirtualBox incluye el comando VBoxManage clonehd, que permite clonar y cambiar de formato de disco. El uso típico para pasar de VMDK a RAW sería algo tal que así:

VBoxManage clonehd fichero_origen.vmdk fichero_destino.dd –format raw

Conviene usar rutas absolutas para evitar problemas, sobre todo si manejas varios discos y directorios. Durante la conversión, VBoxManage recorre todos los bloques del VMDK y los vuelca tal cual al nuevo archivo RAW. Si el VMDK era de tipo dinámico, ten en cuenta que la imagen RAW resultante probablemente ocupará bastante más en el sistema de ficheros de destino.

Es importante asegurarte de que tienes suficiente espacio libre en la unidad donde vas a guardar el RAW, o te encontrarás con errores a media conversión. Una vez completado el proceso, dispondrás de un fichero en formato estándar dd con el que podrás trabajar cómodamente en suites de análisis o incluso mapearlo desde otros hipervisores.

Raw Device Mapping (RDM) en VMware vSphere / ESXi

En el ecosistema de VMware, la forma clásica de dar acceso directo a una LUN física a una máquina virtual es mediante Raw Device Mapping (RDM). Esta técnica se utiliza sobre todo cuando trabajas con cabinas de almacenamiento iSCSI o Fibre Channel y necesitas que la VM vea el volumen casi como si estuviera conectado directamente al sistema.

En vez de crear un disco virtual dentro de un datastore VMFS, RDM crea un archivo especial de mapeo en un volumen VMFS que actúa de enlace simbólico hacia la LUN física. Desde el punto de vista de la VM, ese archivo se presenta como un disco más, pero en realidad los accesos se redirigen al dispositivo en bruto de la cabina.

Este enfoque permite conservar algunas ventajas de VMFS (como la gestión centralizada y parte del control de permisos), mientras que la E/S al disco se realiza directamente contra la LUN. Es especialmente útil en entornos de clúster donde varias máquinas virtuales comparten almacenamiento y necesitan que el sistema invitado gestione el locking, o para aplicaciones que requieren un control muy fino de SCSI.

Cuando configuras un RDM, VMware te da a elegir entre dos modos: modo de compatibilidad virtual y modo de compatibilidad física. La elección determinará qué funciones de VMware sigues pudiendo usar y qué nivel de acceso tiene realmente la VM al dispositivo de almacenamiento.

Modos de compatibilidad: virtual vs física

El modo de compatibilidad virtual hace que el RDM se comporte, de cara a VMware, casi como si fuera un archivo de disco virtual normal. Esto significa que puedes seguir usando funcionalidades como snapshots de la VM, aunque por debajo el almacenamiento sea una LUN en bruto. Es un buen compromiso cuando quieres simplicidad y ciertas funciones de gestión, pero no necesitas acceso SCSI de bajo nivel.

El modo de compatibilidad física, en cambio, le da a la VM un acceso prácticamente directo al dispositivo SCSI. Es la opción apropiada para aplicaciones que requieren comandos SCSI avanzados o gestión propia de multipath, y para determinados escenarios de clúster en los que el sistema operativo invitado se encarga del control total del volumen.

Eso sí, en modo de compatibilidad física perderás parte de la magia de la virtualización: no todos los tipos de snapshot y operaciones de clonación estarán disponibles o se comportarán igual, precisamente porque VMware interfiere lo mínimo posible entre la VM y el disco.

Pasos generales para crear un RDM en VMware

Para crear un RDM, el flujo en el cliente de vSphere suele ser parecido al siguiente. Primero, en una de las máquinas virtuales que van a usar la LUN en bruto:

1. Selecciona la VM y entra en “Edit Settings” desde el menú contextual.
2. Pulsa en Add > Hard Disk para añadir un nuevo disco.
3. Elige la opción Mapped SAN LUN o equivalente.
4. Selecciona la LUN física que quieres mapear desde la cabina.
5. Indica en qué datastore VMFS quieres guardar el archivo de mapeo.
6. Elige Physical o Virtual como modo de compatibilidad, según lo comentado antes.
7. Se creará una nueva controladora SCSI para el disco RDM, seleccionando un nuevo Virtual Device Node (por ejemplo SCSI 3:0) diferente al del disco principal de la VM.

En las demás máquinas virtuales que también vayan a usar esa misma LUN compartida, el procedimiento es similar pero con una diferencia clave: en lugar de crear un nuevo RDM, se reutiliza el que ya existe en el datastore.

En estas VMs adicionales:

1. Abre de nuevo Edit Settings en la VM.
2. Pulsa en Add > Hard Disk.
3. Elige la opción Use Existing Disk para reutilizar el archivo de RDM ya creado.
4. Selecciona el mismo fichero de mapeo del primer paso.
5. Configura la nueva controladora SCSI y el nodo de dispositivo igual que en la primera VM, respetando las recomendaciones de VMware para clústeres.

De este modo, varias máquinas virtuales pueden acceder en bruto a la misma LUN, dejando en manos del sistema operativo invitado o del software de clúster el control de la concurrencia y el acceso simultáneo.

Proxmox VE e imágenes de disco RAW para máquinas virtuales

Proxmox VE es una plataforma de virtualización open source muy completa que permite gestionar tanto máquinas virtuales KVM como contenedores LXC. Una de sus grandes ventajas es la flexibilidad para manejar discos en formato RAW, tanto para crearlos desde cero como para importarlos desde otros entornos y asociarlos a VMs existentes.

Un disco RAW, en este contexto, es un archivo que contiene una copia byte a byte de un disco físico o de una partición. No incorpora compresión ni funcionalidades adicionales; simplemente son todos los bytes del dispositivo en orden. Precisamente por eso es un formato muy compatible y muy cómodo a la hora de migrar máquinas virtuales entre hipervisores o restaurar copias de seguridad con la mínima transformación posible.

En Proxmox, puedes tanto crear tus propias imágenes RAW con herramientas como vmdebootstrap como importar RAWs generados previamente (por ejemplo, volcados dd, conversiones desde VBoxManage o salidas de otros hipervisores) y montarlos como discos en una máquina virtual.

Crear una imagen de disco RAW con vmdebootstrap

Una forma muy práctica de preparar una imagen RAW para Proxmox es usar la utilidad vmdebootstrap, que automatiza la creación de un sistema base dentro de un archivo de imagen. Esta herramienta se encarga de particionar, formatear, instalar el sistema, configurar GRUB y añadir algunos paquetes básicos.

Un ejemplo típico de comando para generar una imagen RAW con una configuración mínima podría incluir opciones como:

vmdebootstrap –verbose –size 10GiB –serial-console –grub –no-extlinux –package openssh-server –package avahi-daemon –package qemu-guest-agent –hostname vm600 –enable-dhcp –customize=./copy_pub_ssh.sh –sparse –image vm600.raw

En este tipo de comando defines parámetros como tamaño del disco, paquetes a instalar, hostname de la VM o activación de consola serie. Al terminar el proceso tendrás un fichero vm600.raw que contiene un sistema Linux completamente funcional, listo para ser importado en Proxmox como disco de una VM.

Crear la máquina virtual y asociar el disco RAW en Proxmox

El siguiente paso consiste en crear la máquina virtual vacía en Proxmox y luego importar el RAW al almacenamiento configurado. Para crear la VM se puede usar el comando qm create, definiendo un ID de VM, la interfaz de red y el tipo de controladora de disco:

qm create 600 –net0 virtio,bridge=vmbr0 –name vm600 –serial0 socket –bootdisk scsi0 –scsihw virtio-scsi-pci –ostype l26

Aquí indicamos, por ejemplo, que queremos que la VM tenga ID 600, que utilice VirtIO para la red con el bridge vmbr0, que arranque por scsi0 con controladora virtio-scsi-pci y que el sistema operativo es un Linux moderno (l26).

Después, importamos la imagen RAW al almacenamiento de Proxmox mediante qm importdisk:

qm importdisk 600 vm600.raw pvedir

En este comando, 600 es el ID de la VM, vm600.raw es la ruta al archivo de imagen y pvedir es el nombre del storage definido en Proxmox (puedes revisarlos con pvesm status). Una vez finalizada la importación, en la configuración de la VM verás el disco como unused0 o similar.

Para que la VM realmente use ese disco, hay que asociarlo a una controladora, por ejemplo SCSI:

qm set 600 –scsi0 pvedir:600/vm-600-disk-1.raw

Así, el disco RAW importado queda vinculado al dispositivo scsi0 de la VM. Por último, solo queda arrancar la máquina con qm start 600 y terminar la configuración desde la consola, como harías con cualquier otra VM.

Subir e importar imágenes RAW grandes a Proxmox

Cuando trabajas con archivos RAW de muchos gigas, subirlos a Proxmox por la interfaz web puede ser poco práctico o directamente inviable. En esos casos se recomienda usar scp, rsync o herramientas similares para copiar la imagen al nodo de Proxmox o al almacenamiento compartido antes de lanzar qm importdisk.

Una vez el archivo se encuentra en el host, el flujo es similar al descrito antes: crear o elegir una VM, importar el disco RAW al storage y asociarlo como dispositivo (scsi0, sata0, etc.), definiendo el tipo de controladora adecuado según el sistema operativo invitado.

Este mismo enfoque sirve para migrar VMs desde otras plataformas: conviertes los discos a RAW (si no lo están ya), los copias al nodo Proxmox, los importas con qm importdisk y por último ajustas la configuración de la VM (drivers de red, controladoras, orden de arranque, etc.) hasta que funcione correctamente.

Copias de seguridad de VMs con discos RAW en Proxmox

Cuando trabajas con imágenes de disco RAW en Proxmox, no debes olvidar la parte de backup y recuperación ante desastres. Además de las copias integradas en Proxmox, existen soluciones de terceros como Vinchin Backup & Recovery que se integran con el hipervisor y permiten una gestión avanzada de copias.

Vinchin ofrece una solución de respaldo diseñada específicamente para entornos virtualizados, incluyendo Proxmox VE. Soporta copias de seguridad completas e incrementales de máquinas virtuales, así como restauraciones granulares o completas. Esto es especialmente útil cuando trabajas con VMs que arrancan desde imágenes RAW importadas, LVM o ZFS, ya que la herramienta se encarga de orquestar todo el proceso sin que tengas que pelearte con los formatos.

El flujo de trabajo suele ser sencillo: seleccionas las VMs que quieres proteger, defines un destino de copia, eliges la política (frecuencia, tipo de backup, retención, etc.) y lanzas el trabajo. El objetivo es que, ante un fallo de hardware o una corrupción en el disco RAW, puedas restaurar la máquina completa en poco tiempo, ya sea en el mismo nodo o en otro host de Proxmox.

Además, Vinchin suele ofrecer periodos de prueba gratuitos, lo que permite evaluar la integración con tu infraestructura antes de decidir su adopción definitiva. En entornos donde la disponibilidad es crítica, combinar Proxmox con una solución de backup sólida es casi obligatorio, especialmente cuando se trabaja con discos RAW que almacenan datos muy sensibles.

Dispositivos RAW para Oracle RAC en Linux

En entornos de base de datos Oracle RAC, el manejo del almacenamiento compartido siempre ha sido un tema delicado. Aunque la mayoría de distribuciones Linux incluyen LVM (Logical Volume Manager), no todas soportan LVM en modo clúster de forma que Oracle lo considere válido para RAC. Por ello, históricamente se ha recurrido con frecuencia al uso de dispositivos RAW dedicados para los componentes críticos.

Para montar este tipo de entorno, primero se instalan los discos compartidos visibles por todos los nodos (por ejemplo, discos presentados por una cabina a varios servidores físicos o VMs). Una vez reconocidos, se reinicia el sistema si es necesario y se identifican los nombres de los dispositivos con herramientas como:

/sbin/fdisk -l

Con fdisk (u otras herramientas modernas como parted) se crean las particiones adecuadas en cada disco: se listan las tablas de particiones con el comando p, se crean nuevas con n y se escriben los cambios con w. Cada una de estas particiones se asociará posteriormente a un raw device específico.

Asociar particiones a dispositivos RAW en Linux

El siguiente paso es comprobar si ya existen raw devices en el sistema. Para ello se puede usar:

/usr/bin/raw -qa

Los dispositivos RAW tradicionales siguen una nomenclatura del tipo /dev/raw/rawn, donde n es un número entero. Cada uno de ellos se puede vincular a una partición de disco, de forma que Oracle (u otras aplicaciones) trabajen siempre con los mismos nombres estables.

La asociación se define en el archivo de configuración /etc/sysconfig/rawdevices, añadiendo una línea por cada partición creada. Por ejemplo:

/dev/raw/raw1 /dev/sda1

En este fichero hay que tener cuidado de utilizar raw devices que no estén ya en uso para evitar conflictos. Una vez definidas las asociaciones, se ajustan propietario, grupo y permisos según el uso que vaya a tener cada dispositivo.

Para el dispositivo RAW destinado al Oracle Cluster Registry (OCR), por ejemplo, se suelen ejecutar comandos como:

chown root:dba /dev/raw/rawn
chmod 640 /dev/raw/rawn

Para el resto de dispositivos RAW que alojarán datafiles o archivos de bases de datos, se ajustan permisos para el usuario y grupo de Oracle:

chown oracle:oinstall /dev/raw/rawn
chmod 660 /dev/raw/rawn

Tras esto, se aplica el binding definido en rawdevices ejecutando:

/sbin/service rawdevices restart

Así, cada partición física queda asociada al raw device correspondiente, listo para su uso por parte de Oracle RAC o cualquier otra aplicación que lo requiera.

Archivo de mapeo de raw devices para DBCA

Para que el asistente Database Configuration Assistant (DBCA) identifique correctamente qué dispositivo RAW corresponde a cada tipo de datafile, es habitual crear un archivo de mapeo. El proceso suele ser algo así:

1. Crear un subdirectorio bajo ORACLE_BASE, por ejemplo:
mkdir -p $ORACLE_BASE/oradata/dbname
2. Ajustar propietario y permisos:
chown -R oracle:oinstall $ORACLE_BASE/oradata
chmod -R 775 $ORACLE_BASE/oradata

Dentro del directorio dbname se crea el fichero dbname_raw.conf con líneas que indiquen qué raw device corresponde a cada tablespace o archivo importante, por ejemplo:

SYSTEM=/dev/raw/raw1
SYSAUX=/dev/raw/raw2
TEMP=/dev/raw/raw3

Finalmente se establece la variable de entorno DBCA_RAW_CONFIG apuntando a ese archivo, de modo que DBCA pueda leerlo durante la creación de la base de datos y asignar cada componente al dispositivo RAW correcto.

Dispositivos RAW y particiones en SUSE Linux Micro con Combustion

SUSE Linux Micro, orientado a despliegues inmutables y de contenedores, se distribuye a menudo en imágenes RAW con un esquema de particionado por defecto. Cuando quieres personalizar ese esquema, mover directorios como /home a otro disco o añadir nuevas particiones, entra en juego Combustion, el sistema de configuración de primer arranque.

Combustion utiliza un archivo llamado script, que contiene comandos ejecutados en una shell transactional-update durante el primer boot. A través de este script puedes crear particiones adicionales, modificar initramfs, definir usuarios, configurar red, añadir claves SSH, instalar paquetes, etc., sin tocar manualmente el sistema una vez instalado.

En estas imágenes, /etc se monta mediante overlayFS, con la capa superior ubicada, por ejemplo, en /var/lib/overlay/1/etc/. Los subvolúmenes montados por defecto se reconocen por opciones como x-initrd.mount en /etc/fstab. Si quieres modificar archivos de un subvolumen no montado por defecto, primero tienes que declararlo para que se monte durante el arranque.

Para configurar red en el primer arranque, Combustion permite añadir una instrucción que pasa el parámetro rd.neednet=1 a dracut, obligando a que se configure red (normalmente por DHCP) durante initramfs. Si necesitas una configuración de red estática, tendrás que usar la sección de cambios en initramfs para escribir tus propios ficheros de NetworkManager o similares.

Ejemplo de trabajo con particiones y /home en SUSE Linux Micro

Un caso habitual es mover el contenido de /home a una partición diferente, por ejemplo un segundo disco /dev/vdb. En el script de Combustion puedes definir un nuevo esquema de particionado GPT con una única partición para /dev/vdb usando sfdisk, y luego formatearla en Btrfs o el sistema de ficheros que elijas.

Como el comando sfdisk puede tardar algo, es buena idea añadir un pequeño sleep después de ejecutarlo, asegurándote de que la tabla de particiones está completamente escrita antes de seguir con el script. A continuación formateas la nueva partición, creas el nuevo punto de montaje, mueves el posible contenido de /home a su nueva ubicación y ajustas /etc/fstab.

El proceso incluye eliminar la entrada antigua de /home en /etc/fstab (si existe) y crear una nueva entrada apuntando al nuevo dispositivo. De este modo, en el siguiente arranque el sistema montará automáticamente la partición recién creada como /home, dejando el resto de la imagen RAW con su particionado original.

Además, Combustion se usa para otras tareas esenciales: definir usuarios no root (por ejemplo para servicios como Cockpit), establecer la contraseña de root usando hashes generados con openssl passwd -6, añadir claves SSH públicas al directorio ~/.ssh/authorized_keys, habilitar servicios (systemctl enable) e incluso instalar paquetes adicionales como vim durante el primer arranque.

En todos los casos, es recomendable asegurarse de que todos los procesos lanzados en background (por ejemplo, tee o similares) finalizan antes de que termine la ejecución de script, añadiendo al final una instrucción que espere a que dichos procesos concluyan para evitar configuraciones incompletas.

Recuperar máquinas virtuales a partir de discos RAW existentes

Un escenario que se repite con cierta frecuencia en entornos de virtualización es el de tener todavía los discos RAW o LVM intactos pero haber perdido la configuración de las VMs. Por ejemplo, cuando falla el disco donde estaba instalado el hipervisor (como un SSD con Proxmox) pero el almacenamiento donde residían los discos de las VMs (un RAID de varios discos) sobrevive.

En una situación así, tras reinstalar el hipervisor (por ejemplo, Proxmox) en un nuevo SSD, lo primero es comprobar si este detecta automáticamente el RAID o el volumen de almacenamiento. Si el sistema ve el RAID y puedes listar los volúmenes o archivos de disco RAW, vas por buen camino: los datos siguen ahí, solo falta volver a engancharlos a nuevas VMs.

Lo que mucha gente echa en falta en estos casos es una opción “mágica” de “volver a registrar todas las VMs” a partir de esos discos. Dependiendo del sistema, es posible que no exista un botón tan directo, y tengas que crear manualmente nuevas máquinas virtuales e ir adjuntando cada disco RAW o LVM a la VM correspondiente.

El truco está en definir en la nueva VM parámetros parecidos a los originales: mismo tipo de BIOS/UEFI, misma controladora de disco (SCSI, VirtIO, SATA…), configuración de red similar, etc. Después, en lugar de crear un disco nuevo, apuntas al volumen RAW o LVM ya existente. Si el sistema operativo que hay dentro del disco no ha sufrido daños, la VM debería ser capaz de arrancar como si nada hubiera pasado.

Esto mismo aplica a otros hipervisores: si pierdes el host de un clúster pero conservas los volúmenes LVM o LUNs con los discos en bruto, puedes volver a registrar o recrear las VMs y reutilizar directamente esos dispositivos como discos, sin necesidad de restaurar copias de seguridad completas (aunque siempre es recomendable tener backups por si algo falla).

Usar imágenes RAW en análisis forense y migraciones entre hipervisores

En el ámbito forense y de la auditoría de seguridad es muy habitual recibir máquinas virtuales completas en formato VMware para analizarlas. Si tu herramienta de trabajo principal no es VMware, o si quieres examinar los datos con suites forenses especializadas, suele ser mucho más cómodo trabajar con un volcado RAW que con un VMDK.

La solución práctica, como ya hemos comentado, consiste en usar VirtualBox y su herramienta VBoxManage para convertir la imagen VMDK en un fichero dd/RAW. Después de la conversión, podrás montar esta imagen en lectura desde Linux, abrirla con herramientas de análisis, o incluso usarla como disco en otros hipervisores que acepten RAW.

Hay que recordar que, cuando el disco original es dinámico, el resultado final en RAW ocupará el tamaño máximo del disco, no el espacio realmente usado. Por tanto, si el VMDK representa un disco de 500 GB, el RAW tenderá a ocupar esos 500 GB, aunque internamente solo se usaran 50 GB. De ahí la importancia de planificar bien el espacio de destino antes de la conversión.

Lo bueno es que, una vez tienes el RAW, las opciones se multiplican: puedes usarlo como origen de migración hacia Proxmox importándolo con qm importdisk, analizarlo bit a bit para obtener evidencias, o incluso escribirle de nuevo cambios si estás haciendo pruebas de laboratorio.

Usar dispositivos e imágenes RAW en máquinas virtuales ofrece un abanico enorme de posibilidades: acceso directo a LUNs para clústeres, reutilización de discos existentes, migraciones entre plataformas, análisis forense y personalización avanzada de sistemas. Eso sí, exige ir con cuidado, documentar bien qué dispositivo es qué y contar siempre con copias de seguridad fiables, porque aquí no hay tanta red de seguridad como con un simple archivo de disco virtual que puedes copiar y pegar sin más.