O QEMU tem várias maneiras de conectar um dispositivo de bloco a uma máquina virtual. Inicialmente, isso foi implementado da seguinte maneira:

-hda /dev/sda1 

Assim, discos virtuais conectados nos velhos tempos da virtualização. Pode ser usado hoje se quisermos apenas testar alguns liveCDs. Infelizmente, tem suas desvantagens. :

• Ao conectar discos virtuais, é possível usar apenas a interface considerada como /dev/hda (hda, hdb, hdc, ..) na máquina virtual; Para CD, a opção -cdrom é -cdrom
• Quando um arquivo (ou dispositivo) é conectado a uma máquina virtual, o QEMU usa apenas as configurações padrão.

dirigir

Para definir outros parâmetros (tipo de barramento, uso de cache etc.), a opção -drive foi adicionada ao -drive . Embora tenha sido originalmente usado para definir parâmetros para o back - end e o front - end , atualmente é usado apenas para definir os parâmetros de back - end , ou seja, parâmetros que afetam a conexão do dispositivo virtual dentro da máquina virtual

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

dispositivo

Definir todos os parâmetros de um dispositivo de bloco com uma opção ao longo do tempo não era razoável. Portanto, as opções foram divididas em duas. Parâmetros de back-end , ou seja, aqueles usados ​​para configurar o ambiente de virtualização. E front-end , que afeta como o dispositivo está conectado na máquina virtual. Para esse conjunto de parâmetros, uma nova opção -device foi introduzida, que contém o ID do ID do inversor especificado pelo parâmetro -drive .

O exemplo de configuração a seguir conectará a unidade ao identificador ide0-hd0 e o resultado será o mesmo que conectar uma unidade virtual, conforme mostrado na introdução.

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

Dispositivos de bloco local em uma máquina virtual

Atualmente, o uso de dispositivos de bloco físico para máquinas virtuais não é generalizado, devido ao uso generalizado de discos virtuais. Tecnicamente, somos capazes de executar uma máquina virtual com algum sistema proprietário a partir de um disco rígido antigo. No entanto, nesse caso, é melhor criar uma imagem de disco usando o dd e iniciar o sistema a partir dele.

Como um dispositivo de bloco local, ele pode ser conectado a uma máquina virtual.

• Matriz RAID local - dispositivo do tipo md
• DRBD principal (rede RAID1) - dispositivo do tipo drbd
• Partição de disco criada no grupo LVM - dispositivo do tipo dm
• Um arquivo comum conectado via loop é um dispositivo de loop

• Bloquear dispositivo de outro computador exportado via servidor NBD - dispositivo do tipo nbd

  
  

  (Aqui também vale a pena mencionar sobre o tipo de dispositivo Ceph rbd e o tipo de dispositivo ZFS zvol - aprox. Por)
  
  

  
  

  NBD

  
  

  Considere o conceito de conectar um dispositivo de bloco de um computador remoto em uma rede. Consulte o manual separado para NBD .

  
  

O QEMU possui uma API NBD integrada, para que um dispositivo de bloco remoto expandido com um servidor NBD possa ser conectado diretamente à máquina virtual via QEMU - veja a figura à esquerda.

No entanto, o NBD é um protocolo bastante simples que não usa autenticação em um servidor remoto e não controla o status da conexão. O protocolo NBD pressupõe que o cliente possa se reconectar se a conexão com o servidor for interrompida, mas infelizmente o QEMU não.

Em parte, a situação pode ser resolvida conectando vários dispositivos NBD e criando uma matriz RAID virtual dentro deles. Essa abordagem tem várias vantagens e uma falha fatal. Se um dos dispositivos desligar, nada de ruim acontecerá. Mas se eles voarem de uma só vez = será ruim. As operações de E / S em um ambiente virtual serão muito mais rápidas, pois as solicitações serão executadas paralelamente a várias máquinas físicas (servidores NBD) de uma só vez. Mas, por outro lado, exigirá mais recursos do processador virtual e da memória virtual.

A principal desvantagem da criação de uma matriz RAID a partir de dispositivos NBD em uma máquina virtual é o dispositivo QEMU; se o dispositivo NBD travar, ele será reconectado somente após uma reinicialização completa da máquina, enquanto uma reinicialização interna do sistema operacional dentro da máquina virtual não será suficiente. Mas você pode criar uma máquina virtual sem discos que acessem independentemente o servidor NBD e conectem os dispositivos NBD necessários. Além disso, os dispositivos com falha devem ser adicionados novamente à matriz e sincronizados novamente, isso pode ser feito manualmente ou usando scripts dentro da máquina virtual.

É melhor acessar o servidor NBD usando o dispositivo da máquina virtual NBD. Especialmente bom, em termos de desempenho de E / S, é a construção de uma matriz RAID a partir de dispositivos NBD.

Essa solução acabou sendo absolutamente a mais produtiva de todas as testadas. E a máquina virtual conseguiu continuar a operação ininterrupta, mesmo no caso de uma desconexão do servidor NBD (ou falha) ao longo do tempo.

Assim, foi possível organizar um ambiente de virtualização relativamente estável e ao mesmo tempo produtivo em equipamentos instáveis.

O principal problema com matrizes RAID em cima de dispositivos NBD é que você precisa ter muito cuidado ao conectar um dispositivo que faz parte de uma matriz RAID a partir do servidor NBD. Esse é um processo bastante delicado, com uma alta probabilidade de erro fatal, que pode levar à perda de dados. Um pequeno erro de digitação é suficiente. Veja a descrição fatal de um acidente de carro em 21 de julho de 2012 na página Amendoins .

A desvantagem é que um dispositivo de bloco com o qual uma máquina virtual já está trabalhando não pode ser conectado em outro local se o seu sistema de arquivos não permitir - isso é semelhante ao iSCSI (Internet Explorer) e ao AoE ( versão em rede do SCSI) ou AoE ( Uma tecnologia da Internet).

Discos virtuais

O QEMU pode conectar não apenas dispositivos de bloco à máquina virtual, mas também, usando várias APIs, um arquivo regular também pode ser conectado, que se parecerá com um dispositivo de bloco dentro da máquina.

Formatos de disco virtual

O Qemu pode trabalhar com discos virtuais de vários formatos. Para os discos virtuais que são apresentados na forma de arquivos comuns, existe um utilitário qemu-img padrão que pode ser usado tanto para a conversão, quanto para determinar o formato usado e seus parâmetros.

Recuperando informações do disco virtual salvas como um arquivo regular. Da mesma maneira, você pode obter informações sobre um disco virtual armazenado no GlusterFS:

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

No entanto, para obter informações sobre um disco virtual usando a API GlusterFS, é necessário usar os mesmos parâmetros usados ​​para conectar o disco virtual à máquina virtual. Assim, você pode identificar o disco interno na máquina em que o cliente GlusterFS está instalado e usado:

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

O disco virtual VDI pode ser identificado apenas através da API Sheepdog:

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

Para um disco virtual exportado do servidor NBD, é necessário garantir que o servidor correto e a porta correta sejam especificados, porque o NBD não usa nenhum outro mecanismo de identificação ou autenticação que elimine a confusão com outros discos virtuais (a nova versão do nbd-server usa apenas uma porta e identifica o dispositivo pelo nome - aprox. por) :

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

192.168.0.2
O endereço IP do host ao qual o dispositivo virtual se conecta. Se esta é a mesma informação qemu-img do host , o localhost pode ser usado em vez do endereço IP

8000
O número da porta na qual o daemon ou servidor está atendendo. Por padrão, o Sheepdog usa a porta 7000, mas também pode ser executada em uma porta diferente para evitar conflitos com outro aplicativo. Um servidor NBD pode escutar em portas diferentes se mais de um dispositivo for exportado.

cru
em geral, é simplesmente um conjunto de dados gravados no mesmo formato que em um dispositivo de bloco convencional. Um arquivo 5G ocupará todo esse lugar, independentemente de conter dados úteis ou apenas espaço vazio. (que não se aplica a arquivos esparsos - aprox. por)

qcow
Ele difere do formato bruto, pois pode ser incremental, porque cresce gradualmente - isso é conveniente para os sistemas de arquivos que não suportam arquivos esparsos, por exemplo, FAT32. Esse formato também permite criar cópias incrementais separadas a partir de um único disco base. Usar esse "modelo" economiza tempo e espaço em disco. Além disso, ele suporta criptografia AES e compactação zlib. A desvantagem é que, diferentemente dos discos brutos, esse arquivo não pode ser montado na máquina diretamente na qual está localizado. Felizmente, existe um utilitário qemu-nbd que pode exportar esse arquivo como um dispositivo de bloco de rede e conectá-lo a um dispositivo NBD.

qcow2
é uma versão atualizada do formato qcow. A principal diferença é que ele suporta instantâneos. Caso contrário, eles não são fundamentalmente diferentes. Também é possível atender ao qcow2, que é definido internamente como QCOW versão 3, uma vez que foi incluído no formato qcow2 há muito tempo. De fato, este é um qcow2 modificado com o parâmetro lazy_refcounts, usado para capturas instantâneas. Como a diferença é de apenas um bit, o qemu-img da versão 1.7 tem a opção "corrigir" para alterá-la. As versões anteriores do qemu-img não. Se você queria alterar a versão do formato, era necessário converter o disco virtual em um novo arquivo. Durante a conversão, o parâmetro compat foi instalado com o parâmetro compat, para o qual foi necessário reduzir "1,1" para 0,10 ". A presença da opção "alterar" é conveniente, pois não há necessidade de substituir os dados devido a essas pequenas alterações.

 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
Esse é um formato incremental de COW de um disco virtual que cria a menor carga no host. Ele não suporta compactação e usa duas tabelas paralelas para endereçar blocos de dados (clusters). Infelizmente, nem um único desenvolvedor estava interessado em seu desenvolvimento por um longo tempo, portanto, seu uso traz alguns problemas que serão mencionados.

vdi
formato de disco virtual usado pelo sistema de virtualização Oracle Virtualbox.

vmdk
formato de disco virtual usado pelos produtos VMware. Este também é um formato que permite que um arquivo cresça gradualmente. No entanto, possui uma grande vantagem sobre os formatos qcow2 e qed, que também podem ser usados ​​com soluções sem disco ou com sistemas de arquivos de rede. Ele permite que você tenha um arquivo de disco virtual dividido em vários arquivos pequenos com tamanhos de 2 GB. Isso permanece desde o momento em que os sistemas de arquivos não puderam criar arquivos maiores que 2 GB. A vantagem é que, se um disco virtual desse tipo for replicado pela rede, menos dados serão transferidos e a sincronização será muito mais rápida (por exemplo, no caso do GlusterFS). No caso de uma solução sem disco, ela também é usada para armazenar apenas arquivos pequenos com diferenças para cada instantâneo

vhdx
formato de disco virtual usado pelo sistema de virtualização Microsoft Hyper-V

vpc
formato de disco virtual usado pelo sistema de virtualização Microsoft VirtualPC.

1. ↑ É possível usar apenas em imagens pré-instaladas (fixas)
   

APIs usadas

Além dos formatos de arquivo, o qemu-img também trabalha com "formatos" fornecidos usando a API através da qual esses dispositivos de bloco podem ser acessados ​​remotamente.

nfs
arquivo de disco virtual conectado ao QEMU via protocolo NFS

iscsi
a comunicação com o dispositivo de bloco é via iSCSI. Um dispositivo não pode ser usado simultaneamente em mais de um cliente.

nbd
O acesso via NBD pode ser muito rápido. Isso ocorre porque o protocolo é muito simples. Isso é uma vantagem, mas ao mesmo tempo uma desvantagem. Isso pode ser conveniente quando vários clientes podem se conectar ao mesmo servidor NBD se eles usarem uma conexão local através do servidor xnbd. No entanto, como o nbd não possui mecanismos de segurança ou autenticação, uma situação pode surgir facilmente quando um cliente acidentalmente se conecta ao dispositivo errado, que no momento especificado já pode ser usado e o danifica.

ssh
a conexão com o servidor remoto é feita via sshfs

gluster
usa a API do sistema de arquivos GlusterFS para acessar o arquivo do disco virtual. Se o arquivo fizer parte de um volume replicado ou distribuído, ele distribuirá os dados armazenados entre outros nós. Isso permite que ele, em caso de falha, esteja disponível em outros nós.

cão pastor
também é um sistema de arquivos distribuídos ativado para replicação. Ao contrário do GlusterFS, um disco virtual por meio da API está disponível não como um arquivo, mas como um dispositivo de bloco. Isso é benéfico em termos de desempenho, mas desvantajoso se precisarmos ir além do ambiente do Sheepdog.

paralelos

Unidades virtuais no armazenamento conectado à rede

A vantagem dos dispositivos de bloco localizados fora do sistema de virtualização é que eles são imunes a falhas da máquina virtual.

Nesse caso, alta disponibilidade e volume suficiente para armazenamento remoto também são fornecidos.

Usando NFS

Cão pastor

GlusterFS

Máquinas virtuais sem bloco

Sem dispositivos de bloco, os sistemas operacionais que podem inicializar via NFS ou com um sistema de arquivos host lançado usando o Plan9 podem funcionar.