Que imagem de disco devo utilizar com a VirtualBox, VDI, VMDK, VHD ou HDD?

VirtualBox tem

• suporte total para
• VDI
• VMDK
• VHD
• suporte parcial para
• HDD (apenas versão Parallels 2)
• e indocumentado suporte para
• QCOW
• QED

Fonte: Oracle® VM VirtualBox® User Manual “ Capítulo 5. Armazenamento Virtual ” 5.2. Ficheiros de Imagem de Disco (VDI, VMDK, VHD, HDD)

• *

Respondendo às suas Considerações

• ser capaz de usar dimensionamento dinâmico

VDI , VMDK , e VHD* todos suportam armazenamento alocado dinamicamente. VMDK tem uma capacidade adicional de dividir o ficheiro de armazenamento em ficheiros com menos de 2 GB cada, o que é útil se o seu sistema de ficheiros tiver um pequeno limite de tamanho.

HDD , QCOW* , e QED* têm de ser alocados dinamicamente se criados na VirtualBox.

• ser capaz de ter snapshots

A VirtualBox suporta snapshotting de todos os seis formatos*.

• ser capaz de mover a minha máquina virtual para outro SO ou mesmo outra solução de virtualização livre com o mínimo esforço (provavelmente algo que correria bem no Ubuntu).

VDI* é o formato nativo da VirtualBox. Outros softwares de virtualização geralmente não suportam VDI, mas é bastante fácil de converter de VDI para outro formato, especialmente com qemu-img convert .

VMDK* é desenvolvido por e para VMWare, mas VirtualBox e QEMU (outro software de virtualização comum) também o suportam. Este formato pode ser a melhor escolha para si porque pretende uma ampla compatibilidade com outro software de virtualização._

VHD é o formato nativo do PC Virtual da Microsoft. O Windows Server 2012 introduziu o VHDX como sucessor do VHD, mas o VirtualBox não suporta VHDX.

HDD é um formato para Parallels . A Parallels é especializada em virtualização para macOS. Provavelmente isto não é adequado para si, especialmente considerando que a VirtualBox suporta apenas uma versão antiga do formato HDD._

QCOW* é a versão original antiga do formato qcow. Foi substituída pela qcow2, que a VirtualBox não suporta.

QED* foi um melhoramento abandonado da qcow2. QEMU desaconselha a utilização do QED.

• performance

Cada um dos formatos pode ter características de performance matizadas devido à forma como o armazenamento em bloco é abstraído pelo formato, mas não encontrei nenhum valor de referência comparando os formatos suportados pela VirtualBox.

Há factores maiores que influenciam o desempenho, tais como:

• as limitações do seu dispositivo físico (muito mais perceptíveis num disco rígido do que numa unidade de estado sólido … *Porquê? * )
• a expansão de uma unidade de disco virtual alocada dinamicamente (as operações de gravação são mais lentas à medida que o disco virtual se expande, mas uma vez que é suficientemente grande, a expansão deve acontecer menos)
• tecnologia de virtualização hardware vs. software ; a virtualização do hardware ajuda a VirtualBox e melhora a velocidade dos sistemas operativos virtuais)
• o facto de estar a correr um sistema operativo virtual. O desempenho é sempre mais lento do que rodar um sistema operativo no host devido à sobrecarga de virtualização.

Eu uso sempre VDI, pois é o formato nativo da VirtualBox; no entanto, a utilização de um VMDK (formato VMWare) irá aumentar a compatibilidade com outro software de máquina virtual.

A VirtualBox funcionará bem no Ubuntu, pelo que se o objectivo for a interoperabilidade Windows/Ubuntu, a VDI seria uma escolha perfeitamente válida.

Ambos os formatos irão satisfazer os seus requisitos.

Quanto aos outros dois, VHD é um formato desenvolvido pela Microsoft, e HDD é um formato desenvolvido pela Apple; ambos são licenciados proprietariamente, pelo que limitam o suporte multiplataforma; eu não os recomendaria.

Mpack, explica aqui uma diferença chave de desempenho entre VHD e VDI:

Tendo estudado recentemente o formato VHD, eu esperaria que houvesse pelo menos uma pequena diferença a favor dos VDIs, mais perceptível quando se está a comparar com similares, ou seja, um VDI optimizado vs um VHD optimizado. A razão é que o formato dinâmico VHD tem estes sectores de “bitmap” espalhados pelo disco. Sempre que modificar um sector dentro de um bloco estes blocos de bitmap podem precisar de ser actualizados e escritos também, envolvendo procura, leitura e escrita extra. Estes sectores bitmap também têm de ser ignorados quando se lêem clusters consecutivos a partir de uma imagem de unidade - mais procuras. O formato VDI não tem estas despesas gerais, especialmente se o VDI foi optimizado (blocos no disco virtual ordenados por ordem LBA).

Todos os meus comentários se aplicam ao formato dinâmico VHD vs VDI dinâmico. Testes de desempenho em discos virtuais de tamanho fixo é inútil uma vez que ambos os formatos são então o mesmo (apenas uma simples imagem de um disco), apenas têm cabeçalhos diferentes. https://forums.virtualbox.org/viewtopic.php?f=1&t=22688

Não sei se a utilização da vmdk lhe permitiria executar de forma transparente uma máquina virtual criada na VirtualBox no VMware ou não. Pode ser que sim. No entanto uma opção mais universal poderia ser utilizar a função Arquivo/Exportação da VirtualBox para criar um ficheiro .ova “Open Virtualization Appliance” que pode depois ser importado para o VMware. Com essa abordagem, pode portar para qualquer sistema de virtualização que suporte .ova sem se preocupar com o formato de imagem de disco que utiliza na VirtualBox.

Se precisar de exportar a partir da mesma VM em intervalos regulares, e.g. todos os dias, isso pode ser uma chatice. Mas se apenas mudar para uma tecnologia diferente ocasionalmente, não deve haver problema.

Se já tem um ficheiro .vdi, pode testar se este funciona sem ter de criar uma nova máquina virtual. Exporte-o para um .ova, depois tente importar com o vmware.

Depende de como você planeja usar o disco virtual também. Nem todas as VM querem uma única partição num único disco.

VDI parece ter mais opções (quando usado com a VirtualBox), mas assim que tira a VirtualBox de cena, o suporte para VDI torna-se algo instável (a partir do final de 2014).

Por exemplo, as minhas soluções precisam de ter o máximo de suporte multi-plataforma. Montar um VDI (como um dispositivo de loopback) no linux ou no Windows 7 é mais difícil e mais difícil do que se poderia esperar. Quase como se o VDI tivesse demasiadas funcionalidades, tornando difícil fazer utilitários totalmente conformes que possam funcionar nele.

O VMDK é apenas menos indolor quando quer que funcione com qualquer VM em qualquer estação de trabalho, quando quer cloná-lo 3 vezes para outros sistemas na rede ao mesmo tempo, e quando quer abri-lo sem lançar uma instância VM.

Apesar de utilizar a VirtualBox 90% do tempo, aquelas poucas vezes em que os meus discos se tornam inacessíveis em determinados fluxos de trabalho levaram-me a favorecer a VMDK para sistemas de ficheiros plugáveis/partilhados.

Os ficheiros de imagem de disco residem no sistema anfitrião e são vistos pelos sistemas convidados como discos rígidos de uma determinada geometria. Quando um sistema operativo convidado lê ou grava num disco rígido, a VirtualBox redirecciona o pedido para o ficheiro de imagem.

Como um disco físico, um disco virtual tem um tamanho (capacidade), que deve ser especificado quando o ficheiro de imagem é criado. No entanto, ao contrário de um disco físico, a VirtualBox permite expandir um ficheiro de imagem após a criação, mesmo que já tenha dados; a VirtualBox suporta quatro variantes de ficheiros de imagem de disco:

VDI: Normalmente, a VirtualBox utiliza o seu próprio formato de contentor para discos rígidos de convidados – ficheiros de imagem de disco virtual (VDI). Em particular, este formato será utilizado quando se cria uma nova máquina virtual com um novo disco.

VMDK:VirtualBox também suporta totalmente o popular e aberto formato de contentor VMDK que é utilizado por muitos outros produtos de virtualização, em particular, pela VMware. [25]

VHD:VirtualBox também suporta totalmente o formato VHD utilizado pela Microsoft.

Ficheiros de imagem de Parallels versão 2 (formato HDD) também são suportados.[26] Por falta de documentação do formato, formatos mais recentes (3 e 4) não são suportados. No entanto, é possível converter esses ficheiros de imagem para o formato da versão 2 utilizando ferramentas fornecidas pela Parallels.

Uma boa razão para eu utilizar a vmdk é que a Virtualbox (pelo menos até à v4.1) utilizando o formato VDI tem a tendência, ao longo do tempo, de preencher todo o espaço em disco atribuído, embora a utilização do disco virtual interno seja ainda muito menor. Com a Virtualbox utilizando discos vmdk, isto parece menos problemático.

Mas estou a falar de anos de uptime. Isto pode não ser um problema que muitas pessoas encontrem.

Parece que a utilização da VDI permite aparar ficheiros de disco ao seu tamanho real VirtualBox e suporte de comando TRIM da SSD

Acabei de migrar um VMDK cru, que foi mapeado para uma partição de um Transcend SSD370 128 GB para um Samsung Pro 850 512GB.

Aparentemente, o VMDK é muito mais rápido do que o VDI. Não percebo porquê, talvez tenha cometido um erro algures.

Copiei o VMDK através do Virtual Media Manager para o 850. Uma vez como VDI, uma vez como VMDK.

Depois corri o hdparm -tT --direct /dev/sda nas imagens. Para cada uma das “runs” troquei o “Machine -> Settings -> Storage -> Controller SATA -> ImageFile.xxx”. A partição bruta no SSD370 foi definida por um ficheiro VMDK, por isso não é realmente uma imagem.

Estes são os resultados:

################################################################################################

Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-96-generic x86_64)

  System information as of Thu Sep 21 17:02:51 CEST 2017

  System load: 1.96 Processes: 201
  Usage of /: 83.2% of 43.88GB Users logged in: 0
  Memory usage: 4% IP address for eth0:    
  Swap usage: 0% IP address for docker0: 172.17.0.1

################################################################################################

======================================================================================
      V M D K --- R A W !!! --- on Transcend SSD370 128 GB
======================================================================================

 Timing O_DIRECT cached reads: 1024 MB in 2.00 seconds = 511.61 MB/sec <---
 Timing O_DIRECT disk reads: 1134 MB in 3.00 seconds = 377.88 MB/sec <---

 Timing O_DIRECT cached reads: 1042 MB in 2.00 seconds = 520.82 MB/sec <---
 Timing O_DIRECT disk reads: 1162 MB in 3.00 seconds = 387.27 MB/sec <---

---

 Timing O_DIRECT cached reads: 816 MB in 2.00 seconds = 407.55 MB/sec
 Timing O_DIRECT disk reads: 1020 MB in 3.01 seconds = 339.43 MB/sec <---

======================================================================================
      V M D K --- on Samsung Pro 850 515GB
======================================================================================

 Timing O_DIRECT cached reads: 836 MB in 2.00 seconds = 417.21 MB/sec <---
 Timing O_DIRECT disk reads: 782 MB in 3.01 seconds = 260.21 MB/sec

 Timing O_DIRECT cached reads: 834 MB in 2.00 seconds = 416.08 MB/sec
 Timing O_DIRECT disk reads: 786 MB in 3.00 seconds = 261.71 MB/sec

---

 Timing O_DIRECT cached reads: 826 MB in 2.00 seconds = 412.75 MB/sec <---
 Timing O_DIRECT disk reads: 774 MB in 3.00 seconds = 257.79 MB/sec

 Timing O_DIRECT cached reads: 828 MB in 2.00 seconds = 413.88 MB/sec <---
 Timing O_DIRECT disk reads: 774 MB in 3.00 seconds = 257.83 MB/sec

---

 Timing O_DIRECT cached reads: 842 MB in 2.00 seconds = 420.76 MB/sec <---
 Timing O_DIRECT disk reads: 770 MB in 3.00 seconds = 256.56 MB/sec

======================================================================================
      V D I --- on Samsung Pro 850 515GB
======================================================================================

 Timing O_DIRECT cached reads: 470 MB in 2.01 seconds = 234.21 MB/sec <---
 Timing O_DIRECT disk reads: 766 MB in 3.00 seconds = 254.94 MB/sec

 Timing O_DIRECT cached reads: 494 MB in 2.00 seconds = 246.45 MB/sec <---
 Timing O_DIRECT disk reads: 754 MB in 3.00 seconds = 250.92 MB/sec

 Timing O_DIRECT cached reads: 490 MB in 2.00 seconds = 244.46 MB/sec <---
 Timing O_DIRECT disk reads: 764 MB in 3.01 seconds = 254.03 MB/sec

################################################################################################
# Data above comes from here
################################################################################################

======================================================================================
      V M D K --- on Samsung Pro 850 515GB
======================================================================================

  System information as of Thu Sep 21 17:02:51 CEST 2017

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 836 MB in 2.00 seconds = 417.21 MB/sec <======
 Timing O_DIRECT disk reads: 782 MB in 3.01 seconds = 260.21 MB/sec <======

user@xeon:~$ sudo hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads: 21080 MB in 2.00 seconds = 10554.40 MB/sec
 Timing buffered disk reads: 784 MB in 3.00 seconds = 260.92 MB/sec

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 834 MB in 2.00 seconds = 416.08 MB/sec <======
 Timing O_DIRECT disk reads: 786 MB in 3.00 seconds = 261.71 MB/sec <======

======================================================================================
      V M D K --- R A W !!! --- on Transcend SSD370 128 GB
======================================================================================

  System information as of Thu Sep 21 17:00:47 CEST 2017

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 1024 MB in 2.00 seconds = 511.61 MB/sec <======
 Timing O_DIRECT disk reads: 1134 MB in 3.00 seconds = 377.88 MB/sec <======

user@xeon:~$ sudo hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads: 21182 MB in 2.00 seconds = 10603.52 MB/sec
 Timing buffered disk reads: 1060 MB in 3.00 seconds = 352.91 MB/sec

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 1042 MB in 2.00 seconds = 520.82 MB/sec <======
 Timing O_DIRECT disk reads: 1162 MB in 3.00 seconds = 387.27 MB/sec <======

======================================================================================
      V M D K --- on Samsung Pro 850 515GB
======================================================================================

  System information as of Thu Sep 21 16:58:12 CEST 2017

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 826 MB in 2.00 seconds = 412.75 MB/sec <======
 Timing O_DIRECT disk reads: 774 MB in 3.00 seconds = 257.79 MB/sec <======

user@xeon:~$ sudo hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads: 22082 MB in 2.00 seconds = 11055.78 MB/sec
 Timing buffered disk reads: 788 MB in 3.01 seconds = 262.11 MB/sec

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 828 MB in 2.00 seconds = 413.88 MB/sec <======
 Timing O_DIRECT disk reads: 774 MB in 3.00 seconds = 257.83 MB/sec <======

======================================================================================
      V D I --- on Samsung Pro 850 515GB
======================================================================================

  System information as of Thu Sep 21 16:55:24 CEST 2017

user@xeon:~$ sudo hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads: 21468 MB in 2.00 seconds = 10747.37 MB/sec
 Timing buffered disk reads: 662 MB in 3.01 seconds = 220.12 MB/sec

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 470 MB in 2.01 seconds = 234.21 MB/sec <======
 Timing O_DIRECT disk reads: 766 MB in 3.00 seconds = 254.94 MB/sec <======

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 494 MB in 2.00 seconds = 246.45 MB/sec <======
 Timing O_DIRECT disk reads: 754 MB in 3.00 seconds = 250.92 MB/sec <======

user@xeon:~$ sudo hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads: 20872 MB in 2.00 seconds = 10448.98 MB/sec
 Timing buffered disk reads: 694 MB in 3.01 seconds = 230.78 MB/sec

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 490 MB in 2.00 seconds = 244.46 MB/sec <======
 Timing O_DIRECT disk reads: 764 MB in 3.01 seconds = 254.03 MB/sec <======

======================================================================================
      V M D K --- on Samsung Pro 850 515GB
======================================================================================

  System information as of Thu Sep 21 16:52:32 CEST 2017

user@xeon:~$ sudo hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads: 20872 MB in 2.00 seconds = 10448.90 MB/sec
 Timing buffered disk reads: 764 MB in 3.01 seconds = 254.11 MB/sec

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 842 MB in 2.00 seconds = 420.76 MB/sec <======
 Timing O_DIRECT disk reads: 770 MB in 3.00 seconds = 256.56 MB/sec <======

======================================================================================
      V M D K --- R A W !!! --- on Transcend SSD370 128 GB
======================================================================================

  System information as of Thu Sep 21 16:29:55 CEST 2017

user@xeon:~$ sudo hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads: 22034 MB in 2.00 seconds = 11029.82 MB/sec
 Timing buffered disk reads: 990 MB in 3.00 seconds = 329.68 MB/sec

user@xeon:~$ sudo hdparm -tT --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads: 816 MB in 2.00 seconds = 407.55 MB/sec <======
 Timing O_DIRECT disk reads: 1020 MB in 3.01 seconds = 339.43 MB/sec <======

Não sei bem como interpretar isto, talvez alguém queira deixar um comentário sobre isto. Escolhi então o VMDK.

O VDI é muito mais fácil de compactar se o VM crescer demasiado.

Há muito tempo atrás fiz um teste, converti vdi dinâmico em vhd dinâmico apenas para testar a velocidade e o tamanho dos ficheiros.

Lembrem-se que era um Windows guest inmutable limpe os instalar com algumas aplicações, lembrem-se que para o meu teste converto um formato para outro, por isso ambos são supostos ter a mesma imagem exacta, como fazer uma clonagem.

Para um tamanho de disco de 64GiB, o tamanho do ficheiro VDI era arround 18GiB, enquanto o tamanho do ficheiro VHD arround 22GiB.

Lembro-me que vi estas duas coisas:

1. O tempo de inicialização foi significantemente diferente, se não me lembro que o vhd ruim foi 1,6 vezes mais rápido que o VDI
2. O tamanho do VHD era muito maior do que o VDI, cerca de 4GiB gigabytes maiores que 18GiB, portanto 1,2 vezes maior.

Isso foi há muito tempo e o teste foi feito num HDD, mas eu asseguro que ambos os ficheiros estavam desfragmentados e um ao lado do outro na parte rápida do disco.

Espero que alguém consiga fazer testes SSD reais, mas a minha sensação é que o VHD é mais rápido (e maior) do que o VDI.

Apenas uma dica: VHD/VHDX pode ser compactado directamente em qualquer Windows 7 e Up utilizando a ferramenta de linha de comando DiskPart, para VDI é necessária uma ferramenta externa CloneVDI.

Desculpe não ter testado VMDK, não sabia como compactá-lo sem alterar o seu UUID (o UUID do disco), lembre-se que as ferramentas de comando VBOX sempre o alteram em cada clone, independentemente do formato que utiliza.