QEMU tiene varias formas de conectar un dispositivo de bloque a una máquina virtual. Inicialmente, esto se implementó de la siguiente manera:

-hda /dev/sda1 

Por lo tanto, discos virtuales conectados en los viejos tiempos de la virtualización. Se puede usar hoy si solo queremos probar algunos liveCDs. Desafortunadamente, tiene sus inconvenientes. :

• Al conectar discos virtuales, es posible usar solo la interfaz que se considera como /dev/hda (hda, hdb, hdc, ..) en la máquina virtual; Para CD, se -cdrom opción -cdrom
• Cuando un archivo (o dispositivo) está conectado a una máquina virtual, QEMU usa solo la configuración predeterminada.

conducir

Para establecer otros parámetros (tipo de bus, uso de caché, etc.), se agregó la opción -drive a -drive . Aunque originalmente se usó para establecer parámetros tanto para el backend como para el frontend , en la actualidad solo se usa para establecer los parámetros del backend , es decir, los parámetros que afectan la conexión del dispositivo virtual dentro de la máquina virtual

 -drive file=/dev/sda1,if=ide,cache=writeback,aio=threads 

dispositivo

Establecer todos los parámetros de un dispositivo de bloque con una opción a lo largo del tiempo resultó ser irrazonable. Por lo tanto, las opciones se dividieron en dos. Parámetros de fondo, es decir, aquellos que se utilizan para configurar el entorno de virtualización. Y frontend , que afectan cómo se conecta el dispositivo en la máquina virtual. Para este conjunto de parámetros, se introdujo una nueva opción -device , que contiene la identificación de la identificación de la unidad especificada por el parámetro -drive .

El siguiente ejemplo de configuración conectará la unidad con el identificador ide0-hd0 , y el resultado es el mismo que conectar una unidad virtual, como se muestra en la introducción.

 -drive file=/dev/sda1,id=ide0-hd0,if=none,cache=writeback,aio=threads \ -device ide-drive,bus=ide.0,drive=ide0-hd0 

Dispositivos de bloque local en una máquina virtual.

El uso de dispositivos de bloque físico para máquinas virtuales no está muy extendido en la actualidad debido al uso generalizado de discos virtuales. Técnicamente, podemos ejecutar una máquina virtual con algún sistema patentado desde un disco duro antiguo. Sin embargo, en este caso, es mejor hacer primero una imagen de disco (imagen) usando dd e iniciar el sistema desde allí.

Al igual que un dispositivo de bloque local, se puede conectar a una máquina virtual.

• Matriz RAID local: dispositivo de tipo md
• Master DRBD (red RAID1) - dispositivo de tipo drbd
• Partición de disco creada en el grupo LVM - dispositivo de tipo dm
• Un archivo normal conectado a través de un bucle es un dispositivo de bucle

• Bloquear dispositivo desde otra computadora exportada a través del servidor NBD - dispositivo de tipo nbd

  
  

  (Aquí también vale la pena mencionar sobre el tipo de dispositivo Ceph rbd y el tipo de dispositivo ZFS zvol - aprox. Por)
  
  

  
  

  NBD

  
  

  Considere el concepto de conectar un dispositivo de bloque desde una computadora remota a través de una red. Vea el manual separado para NBD .

  
  

QEMU tiene una API NBD integrada, por lo que un dispositivo de bloque remoto expandido con un servidor NBD se puede conectar directamente a la máquina virtual a través de QEMU; vea la figura a la izquierda.

Sin embargo, NBD es un protocolo bastante simple que no utiliza autenticación en un servidor remoto y no controla el estado de la conexión. El protocolo NBD supone que el cliente puede reconectarse si se interrumpe la conexión al servidor, pero desafortunadamente QEMU no.

En parte, la situación se puede resolver conectando varios dispositivos NBD y creando una matriz RAID virtual dentro de ellos. Este enfoque tiene varias ventajas y un defecto fatal. Si uno de los dispositivos se apaga, no pasará nada malo. Pero si vuelan de una vez = será malo. Las operaciones de E / S en un entorno virtual serán mucho más rápidas, ya que las solicitudes se ejecutarán en paralelo a varias máquinas físicas (servidores NBD) a la vez. Pero, por otro lado, requerirá más recursos del procesador virtual y la memoria virtual.

El principal inconveniente de construir una matriz RAID a partir de dispositivos NBD en una máquina virtual es el dispositivo QEMU, si el dispositivo NBD se bloquea, se volverá a conectar solo después de un reinicio completo de la máquina, mientras que un reinicio interno del sistema operativo dentro de la máquina virtual no será suficiente. Pero puede crear una máquina virtual sin discos que accederá de forma independiente al servidor NBD y conectará los dispositivos NBD necesarios. Además, los dispositivos fallidos se deben volver a agregar a la matriz y volver a sincronizar, esto se puede hacer manualmente o mediante secuencias de comandos dentro de la máquina virtual.

Es mejor acceder al servidor NBD utilizando el dispositivo de máquina virtual NBD. Especialmente bueno, en términos de rendimiento de E / S, es construir una matriz RAID a partir de dispositivos NBD.

Esta solución resultó ser absolutamente la más productiva de todas las probadas. Y la máquina virtual pudo continuar la operación ininterrumpida incluso en el caso de una desconexión del servidor NBD (o falla) con el tiempo.

Por lo tanto, fue posible organizar un entorno de virtualización relativamente estable y al mismo tiempo productivo en equipos inestables.

El principal problema con las matrices RAID en la parte superior de los dispositivos NBD es que debe tener mucho cuidado al conectar un dispositivo que forma parte de una matriz RAID desde el servidor NBD. Este es un proceso bastante delicado con una alta probabilidad de un error fatal, que puede conducir a la pérdida de datos. Un pequeño error tipográfico es suficiente. Vea la descripción del accidente automovilístico fatal del 21 de julio de 2012 en la página Peanuts .

La desventaja es que un dispositivo de bloque con el que una máquina virtual ya está funcionando no se puede conectar en otro lugar si su sistema de archivos no lo permite; esto es similar a iSCSI (interfaz de Internet del centro comercial del centro de Internet, versión de red de SCSI) o AoE ( Una tecnología TA o ver E thernet).

Discos virtuales

QEMU puede conectar no solo dispositivos de bloque a la máquina virtual, sino también, utilizando varias API, también se puede conectar un archivo normal, que se verá como un dispositivo de bloque dentro de la máquina.

Formatos de disco virtual

Qemu puede trabajar con discos virtuales de varios formatos. Para aquellos discos virtuales que se presentan en forma de archivos ordinarios, existe una utilidad qemu-img estándar que se puede usar tanto para la conversión como para determinar el formato utilizado y sus parámetros.

Recuperando información del disco virtual guardada como un archivo normal. Del mismo modo, puede obtener información sobre un disco virtual almacenado en GlusterFS:

 root@stroj~# qemu-img info /path_to_file/soubor.img 

Sin embargo, para obtener información sobre un disco virtual utilizando la API de GlusterFS, debe usar los mismos parámetros que se utilizan para conectar el disco virtual a la máquina virtual. Para que pueda identificar el disco interno en la máquina donde está instalado y utilizado el cliente GlusterFS:

 root@stroj~# qemu-img info gluster+tcp://192.168.0.2/volume_name/soubor.img 

El disco virtual VDI solo se puede identificar a través de la API Sheepdog:

 root@stroj~# qemu-img info sheepdog:192.168.0.2:8000:vdi_name 

Para un disco virtual exportado desde el servidor NBD, es necesario asegurarse de que se especifique el servidor correcto y el puerto correcto, porque NBD no usa ningún otro mecanismo de identificación o autenticación que elimine la confusión con otros discos virtuales (la nueva versión de nbd-server usa solo un puerto e identifica el dispositivo por nombre - aprox. por) :

 root@stroj~# qemu-img info nbd:192.168.0.2:8000 

192.168.0.2
La dirección IP del host desde el cual se conecta el dispositivo virtual. Si este es el mismo host en el que se está ejecutando la información qemu-img , se puede usar localhost en lugar de la dirección IP

8000
El número de puerto en el que escucha el daemon o el servidor. De forma predeterminada, Sheepdog usa el puerto 7000, pero también se puede ejecutar en un puerto diferente para evitar conflictos con otra aplicación. Un servidor NBD puede escuchar en diferentes puertos si se exporta más de un dispositivo.

crudo
en general, es simplemente un conjunto de datos grabados en el mismo formato que en un dispositivo de bloque convencional. Un archivo 5G ocupará todo este lugar, independientemente de si contiene datos útiles o solo espacio vacío. (que no se aplica a archivos dispersos - aprox. por)

qcow
Se diferencia del formato sin formato en que puede ser incremental, porque crece gradualmente; esto es conveniente para aquellos sistemas de archivos que no admiten archivos dispersos, por ejemplo FAT32. Este formato también le permite crear copias incrementales separadas desde un solo disco base. El uso de dicha "plantilla" ahorra tiempo y espacio en disco. Además, admite cifrado AES y compresión zlib. La desventaja es que, a diferencia de los discos en bruto, dicho archivo no se puede montar en la máquina directamente en la que se encuentra. Afortunadamente, hay una utilidad qemu-nbd que puede exportar este archivo como un dispositivo de bloqueo de red y luego conectarlo a un dispositivo NBD.

qcow2
es una versión actualizada del formato qcow. La principal diferencia es que admite instantáneas. De lo contrario, no son fundamentalmente diferentes. También es posible cumplir con qcow2, que se define internamente como QCOW versión 3, una vez que se incluyó en el formato qcow2 hace mucho tiempo. De hecho, este es un qcow2 modificado con el parámetro lazy_refcounts, que se usa para instantáneas. Como la diferencia es de solo un bit, qemu-img de la versión 1.7 tiene la opción "modificar" para cambiarla. Las versiones anteriores de qemu-img no lo hacen. Si quería cambiar la versión del formato, era necesario convertir el disco virtual a un nuevo archivo, durante la conversión, el parámetro compat se instaló con el parámetro compat, para lo cual fue necesario reducir el "1.1" a 0.10 ". La presencia de la opción "enmendar" es conveniente porque no es necesario sobrescribir los datos debido a cambios menores.

 qemu-img create -f qcow2 -o compat=1.1 test.qcow2 8G 

http://blog.wikichoon.com/2014/12/virt-manager-10-creates-qcow2-images.html

qed
Este es un formato COW incremental de un disco virtual que crea la menor carga en el host. No admite ninguna compresión y utiliza dos tablas paralelas para direccionar bloques de datos (clústeres). Desafortunadamente, ningún desarrollador estuvo interesado en su desarrollo durante mucho tiempo, por lo que su uso trae algunos problemas que se mencionarán.

vdi
formato de disco virtual utilizado por el sistema de virtualización Oracle Virtualbox.

vmdk
formato de disco virtual utilizado por los productos VMware. Este también es un formato que permite que un archivo crezca gradualmente. Sin embargo, tiene una gran ventaja sobre los formatos qcow2 y qed, que también se pueden usar con soluciones sin disco o con sistemas de archivos de red. Le permite tener un archivo de disco virtual dividido en varios archivos pequeños con tamaños de 2 GB. Esto permanece desde el momento en que los sistemas de archivos no podían crear archivos de más de 2 GB. La ventaja es que si dicho disco virtual se replica a través de la red, se transfieren menos datos y la sincronización es mucho más rápida (por ejemplo, en el caso de GlusterFS). En el caso de una solución sin disco, también se usa para almacenar solo archivos pequeños con diferencias para cada instantánea

vhdx
formato de disco virtual utilizado por el sistema de virtualización Microsoft Hyper-V

vpc
formato de disco virtual utilizado por el sistema de virtualización Microsoft VirtualPC.

1. ↑ Es posible usar solo en imágenes preinstaladas (fijo)
   

API utilizadas

Además de los formatos de archivo, qemu-img también funciona con "formatos" que se proporcionan utilizando la API a través de la cual se puede acceder a estos dispositivos de bloque de forma remota.

nfs
archivo de disco virtual conectado a QEMU a través del protocolo NFS

iscsi
La comunicación con el dispositivo de bloqueo se realiza a través de iSCSI. No se puede usar un dispositivo simultáneamente en más de un cliente.

nbd
El acceso a través de NBD puede ser muy rápido. Esto se debe a que el protocolo es muy simple. Esto es una ventaja, pero al mismo tiempo una desventaja. Esto puede ser conveniente cuando varios clientes pueden conectarse al mismo servidor NBD si usan una conexión local a través del servidor xnbd. Sin embargo, dado que nbd no tiene mecanismos de seguridad o autenticación, una situación puede surgir fácilmente cuando un cliente se conecta accidentalmente al dispositivo incorrecto, que en el momento dado ya puede usarse y dañarlo.

ssh
la conexión al servidor remoto se realiza a través de sshfs

brillo
utiliza la API del sistema de archivos GlusterFS para acceder al archivo del disco virtual. Si el archivo es parte de un volumen replicado o distribuido, distribuirá los datos almacenados entre otros nodos. Esto le permite, en caso de falla, estar disponible en otros nodos.

perro pastor
también es un sistema de archivos distribuido habilitado para replicación. A diferencia de GlusterFS, un disco virtual a través de la API no está disponible como un archivo, sino como un dispositivo de bloque. Esto es beneficioso en términos de rendimiento, pero es desventajoso si necesitamos ir más allá del entorno de Sheepdog.

paralles

Unidades virtuales en almacenamiento conectado a la red

La ventaja de los dispositivos de bloque ubicados fuera del sistema de virtualización es que son inmunes a fallas de máquinas virtuales.

En este caso, también se proporciona alta disponibilidad y volumen suficiente para el almacenamiento remoto.

Usando NFS

Perro pastor

GlusterFS

Máquinas virtuales sin bloques

Sin dispositivos de bloque, los sistemas operativos que pueden arrancar a través de NFS o con un sistema de archivos host lanzado con Plan9 pueden funcionar.