Quelle image disque dois-je utiliser avec VirtualBox, VDI, VMDK, VHD ou HDD ?

VirtualBox a

• support complet pour
• VDI
• VMDK
• VHD
• support partiel pour
• HDD (Parallels version 2 uniquement)
• et undocumented support pour
• QCOW
• QED

Source : Oracle® VM VirtualBox® User Manual “ Chapter 5. Virtual Storage ” 5.2. Disk Image Files (VDI, VMDK, VHD, HDD)

Answering Your Considerations

• pouvoir utiliser le dimensionnement dynamique

VDI , VMDK , et VHD prennent tous en charge le stockage alloué dynamiquement. VMDK a une capacité supplémentaire de fractionnement du fichier de stockage en fichiers de moins de 2 Go chacun, ce qui est utile si votre système de fichiers a une limite de taille de fichier réduite.

HDD , QCOW , et QED doivent être alloués dynamiquement s'ils sont créés dans VirtualBox. 002

• pouvoir disposer d'instantanés 002 VirtualBox supporte l'instantané de tous les six formats. 002
• pouvoir déplacer ma machine virtuelle vers un autre OS ou même une autre solution de virtualisation gratuite avec un minimum d'effort (probablement quelque chose qui fonctionnerait bien sur Ubuntu). 002 VDI est le format natif de VirtualBox. Les autres logiciels de virtualisation ne prennent généralement pas en charge la VDI, mais il est assez facile de convertir la VDI en un autre format, en particulier avec qemu-img convert .

VMDK est développé par et pour VMWare, mais VirtualBox et QEMU (un autre logiciel de virtualisation courant) le prennent également en charge. Ce format pourrait être le meilleur choix pour vous car vous souhaitez une large compatibilité avec d'autres logiciels de virtualisation._

VHD est le format natif de Microsoft Virtual PC. Windows Server 2012 a introduit le VHDX comme successeur du VHD, mais VirtualBox ne prend pas en charge le VHDX.

HDD est un format pour Parallels . Parallels est spécialisé dans la virtualisation pour macOS. Cela ne vous convient probablement pas, surtout si l'on considère que VirtualBox ne prend en charge qu'une ancienne version du format HDD.

QCOW est l'ancienne version originale du format qcow. Elle a été remplacée par qcow2, que VirtualBox ne prend pas en charge.

QED était une amélioration abandonnée de qcow2. QEMU déconseille l'utilisation de QED. ](https://wiki.qemu.org/Features/QED)

• performance

Chacun des formats peut avoir des caractéristiques de performance nuancées en raison de la façon dont le stockage en bloc est abstrait par le format, mais je n'ai pas trouvé de benchmarks comparant les formats supportés par VirtualBox. Il existe des facteurs plus importants qui influencent les performances, tels que :

• les limites de votre périphérique physique (beaucoup plus visibles sur un disque dur qu'un solid-state drive … [ *Pourquoi ? * )
• l'expansion d'un disque virtuel alloué dynamiquement (les opérations d'écriture sont plus lentes lorsque le disque virtuel s'étend, mais une fois qu'il est suffisamment grand, l'expansion devrait être moindre)
• la technologie de virtualisation matériel contre logiciel ; la virtualisation matérielle aide VirtualBox et améliore la vitesse des systèmes d'exploitation virtuels)
• le fait que vous utilisez un système d'exploitation virtuel. Les performances sont toujours plus lentes que l'exécution d'un système d'exploitation sur l'hôte en raison de la surcharge de virtualisation.

J'utilise toujours VDI, car c'est le format natif de VirtualBox ; cependant, l'utilisation d'un VMDK (format VMWare) augmentera la compatibilité avec d'autres logiciels de machines virtuelles.

VirtualBox fonctionnera bien sur Ubuntu, donc si le but est l'interopérabilité Windows/Ubuntu, VDI serait un choix parfaitement valable. Les deux formats répondront à vos besoins. Comme pour les deux autres, VHD est un format développé par Microsoft et le disque dur est un format développé par Apple ; ils sont tous deux sous licence propriétaire, ce qui limite le support multiplateforme ; je ne les recommanderais pas.

Mpack, explique une différence de performance clé entre VHD et VDI ici :

Ayant récemment étudié le format VHD, je m'attendrais à ce qu'il y ait au moins une petite différence en faveur des VDI, plus perceptible lorsque vous comparez des produits similaires, c'est-à-dire une VDI optimisée contre une VHD optimisée. La raison en est que le format VHD dynamique a ces secteurs “bitmap” dispersés sur le disque. Chaque fois que vous modifiez un secteur à l'intérieur d'un bloc, ces blocs bitmap peuvent avoir besoin d'être mis à jour et écrits également, ce qui implique des recherches, des lectures et des écritures supplémentaires. Ces secteurs bitmap doivent également être ignorés lors de la lecture de grappes consécutives à partir d'une image de disque - ce qui implique des recherches supplémentaires. Le format VDI n'a pas ces surcharges, surtout si le VDI a été optimisé (blocs sur le disque virtuel triés dans l'ordre LBA).

Tous mes commentaires s'appliquent au format VHD dynamique par rapport au VDI dynamique. Les tests de performance sur des disques virtuels de taille fixe sont inutiles puisque les deux formats sont alors identiques (juste une image simple d'un disque), ils ont juste des en-têtes différents. https://forums.virtualbox.org/viewtopic.php?f=1&t=22688

Je ne sais pas si l'utilisation de vmdk vous permettrait de faire fonctionner de manière transparente une machine virtuelle créée dans VirtualBox dans VMware ou non. C'est possible. Cependant, une option plus universelle pourrait être d'utiliser la fonction File/Export de VirtualBox pour créer un fichier .ova “Open Virtualization Appliance” qui peut ensuite être importé dans VMware. Avec cette approche, vous pouvez porter vers n'importe quel système de virtualisation qui supporte le .ova sans vous soucier du format d'image disque que vous utilisez dans VirtualBox.

Si vous devez exporter à partir de la même VM à intervalles réguliers, par exemple tous les jours, cela pourrait être une difficulté. Mais si vous ne passez à une autre technologie qu'occasionnellement, cela devrait aller.

Si vous avez déjà un fichier .vdi, vous pouvez tester si cela fonctionne sans avoir à créer une nouvelle machine virtuelle. Exportez-le vers un fichier .ova, puis essayez de l'importer avec vmware.

Cela dépend également de la manière dont vous prévoyez d'utiliser le disque virtuel. Toutes les VM ne veulent pas une seule partition sur un seul disque.

La VDI semble avoir plus d'options (lorsqu'elle est utilisée avec VirtualBox), mais dès que vous retirez VirtualBox de l'image, le support de la VDI devient quelque peu bancal (à partir de fin 2014).

Par exemple, mes solutions doivent avoir un support multiplateforme maximum. Le montage d'une VDI (comme un dispositif de bouclage) sur linux ou Windows 7 est plus difficile et plus bogué que vous ne le pensez. Presque comme la VDI a trop de fonctionnalités, il est difficile de faire des utilitaires totalement conformes qui peuvent fonctionner dessus.

VMDK est juste un IMHO moins douloureux quand vous voulez qu'il fonctionne avec n'importe quelle VM sur n'importe quel poste de travail, quand vous voulez le cloner 3 fois vers d'autres systèmes sur le réseau en même temps, et quand vous voulez l'ouvrir sans lancer une instance de VM.

Même si j'utilise VirtualBox 90% du temps, les rares fois où mes disques deviennent inaccessibles dans certains flux de travail m'ont conduit à privilégier VMDK pour les systèmes de fichiers enfichables/partagés.

Les fichiers d'image disque résident sur le système hôte et sont vus par les systèmes invités comme des disques durs d'une certaine géométrie. Lorsqu'un système d'exploitation invité lit ou écrit sur un disque dur, VirtualBox redirige la requête vers le fichier image.

Comme un disque physique, un disque virtuel a une taille (capacité), qui doit être spécifiée lors de la création du fichier image. Cependant, contrairement à un disque physique, VirtualBox vous permet de développer un fichier image après sa création, même s'il contient déjà des données ; VirtualBox prend en charge quatre variantes de fichiers image de disque :

VDI : normalement, VirtualBox utilise son propre format de conteneur pour les disques durs invités – les fichiers image de disque virtuel (VDI). Ce format sera notamment utilisé lorsque vous créerez une nouvelle machine virtuelle avec un nouveau disque.

VMDK : VirtualBox prend également entièrement en charge le format conteneur VMDK, populaire et ouvert, qui est utilisé par de nombreux autres produits de virtualisation, notamment par VMware. Les fichiers image de la version 2 de Parallels (format HDD) sont également pris en charge[26]. Par manque de documentation sur ce format, les formats plus récents (3 et 4) ne sont pas pris en charge. Vous pouvez cependant convertir ces fichiers d'images au format de la version 2 en utilisant les outils fournis par Parallels.

Une bonne raison pour moi d'utiliser vmdk est que Virtualbox (au moins jusqu'à la v4.1) utilisant le format VDI a tendance, avec le temps, à remplir tout l'espace disque alloué, même si l'utilisation du disque virtuel interne est encore beaucoup moins importante. Avec Virtualbox utilisant des disques vmdk, cela semble moins problématique.

Mais je parle d'années de disponibilité. Ce n'est peut-être pas un problème que beaucoup de gens rencontrent.

Il semble que l'utilisation de la VDI permette de découper le fichier disque à sa taille réelle VirtualBox et support de la commande TRIM du SSD

Je viens de migrer un VMDK brut, qui a été mappé sur une partition d'un Transcend SSD370 128 Go vers un Samsung Pro 850 512 Go.

Apparemment, le VMDK est beaucoup plus rapide que le VDI. Je ne comprends pas pourquoi, j'ai peut-être fait une erreur quelque part.

J'ai copié le VMDK via le Virtual Media Manager sur le 850. Une fois comme VDI, une fois comme VMDK.

Puis j'ai lancé hdparm -tT --direct /dev/sda sur les images. Pour chacun des “runs”, j'ai remplacé le “Machine -> Settings -> Storage -> Controller SATA -> ImageFile.xxx”. La partition brute sur SSD370 était définie par un fichier VMDK, donc ce n'est pas vraiment une image.

Voici les résultats :

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

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 <======

Je ne sais pas vraiment comment interpréter cela, peut-être que quelqu'un veut laisser un commentaire dessus. J'ai donc choisi le VMDK.

La VDI est beaucoup plus facile à compacter si la VM devient trop grande.

Il y a longtemps, j'ai fait un test, convertir dynamic vdi en dynamic vhd juste pour tester la vitesse et la taille des fichiers.

Souvenez-vous que c'était un client Windows inmuable qui s'installe avec quelques applications, souvenez-vous que pour mon test je convertis un format à un autre, donc les deux sont supposés avoir exactement la même image, comme pour un clonage. Pour une taille de disque de 64GiB, la taille du fichier VDI était d'environ 18GiB, alors que la taille du fichier VHD était d'environ 22GiB. Je me souviens avoir vu ces deux choses :

1. Le temps de démarrage était significativement différent, si je ne me souviens pas, un mauvais VHD était 1,6 fois plus rapide que le VDI
2. La taille du VHD était beaucoup plus grande que celle du VDI, environ 4GiB gigaoctets de plus qu'un 18GiB, donc 1,2 fois plus grande.

C'était il y a longtemps et le test a été fait sur un disque dur, mais j'ai fait en sorte que les deux fichiers soient défragmentés et juxtaposés sur la partie rapide du disque.

J'espère que quelqu'un pourra faire de vrais tests SSD, mais mon sentiment est que le VHD est plus rapide (et plus grand) que le VDI.

Juste un conseil : VHD/VHDX peut être compacté directement sur n'importe quel Windows 7 et supérieur en utilisant l'outil en ligne de commande DiskPart, pour la VDI il faut un outil externe CloneVDI.

Désolé je n'ai pas testé VMDK, je ne savais pas comment le compacter sans changer son UUID (l'UUID du disque), souvenez-vous que les outils de commande VBOX le changent toujours sur chaque clone, quel que soit le format utilisé.