Welches Festplatten-Image sollte ich mit VirtualBox, VDI, VMDK, VHD oder HDD verwenden?

VirtualBox hat

• volle Unterstützung für
• VDI
• VMDK
• VHD
• teilweise Unterstützung für
• HDD (nur Parallels Version 2)
• und undokumentierte Unterstützung für
• QCOW
• QED

Quelle: Oracle® VM VirtualBox® Benutzerhandbuch “ Kapitel 5. virtueller Speicher ” 5.2. Disk Image Files (VDI, VMDK, VHD, HDD)

Ihre Überlegungen beantworten

• dynamische Größenanpassung verwenden können

VDI , VMDK und VHD alle unterstützen dynamisch zugewiesenen Speicher. VMDK bietet zusätzlich die Möglichkeit, die Speicherdatei in Dateien von jeweils weniger als 2 GB aufzuteilen, was nützlich ist, wenn Ihr Dateisystem eine kleine Dateigrößenbeschränkung hat.

HDD , QCOW und QED müssen dynamisch zugewiesen werden, wenn sie in VirtualBox erstellt wurden.

• in der Lage sein, Snapshots zu haben

VirtualBox unterstützt Snapshots von allen sechs Formaten.

• in der Lage sein, meine virtuelle Maschine mit minimalem Aufwand auf ein anderes Betriebssystem oder sogar eine andere freie Virtualisierungslösung zu verschieben (wahrscheinlich etwas, das unter Ubuntu gut laufen würde).

VDI ist das native Format von VirtualBox. Andere Virtualisierungssoftware unterstützt in der Regel keine VDI, aber es ist ziemlich einfach, von VDI in ein anderes Format zu konvertieren, besonders mit qemu-img convert .

VMDK wird von und für VMWare entwickelt, aber VirtualBox und QEMU (eine andere gebräuchliche Virtualisierungssoftware) unterstützen es ebenfalls. Dieses Format könnte die beste Wahl für Sie sein, da Sie eine breite Kompatibilität mit anderer Virtualisierungssoftware wünschen._

VHD ist das native Format von Microsoft Virtual PC. Windows Server 2012 führte VHDX als Nachfolger von VHD ein, aber VirtualBox unterstützt VHDX nicht.

HDD ist ein Format für Parallels . Parallels hat sich auf die Virtualisierung für MacOS spezialisiert. Das ist wahrscheinlich nicht für Sie geeignet, besonders wenn man bedenkt, dass VirtualBox nur eine alte Version des HDD-Formats unterstützt.

QCOW ist die alte Originalversion des qcow-Formats. Sie wurde durch qcow2 ersetzt, das von VirtualBox nicht unterstützt wird.

QED war eine aufgegebene Erweiterung von qcow2. QEMU rät von der Verwendung von QED ab.

• Leistung

Jedes der Formate kann aufgrund der Art und Weise, wie der Blockspeicher durch das Format abstrahiert wird, nuancierte Leistungsmerkmale aufweisen, aber ich habe keine Benchmarks zum Vergleich der von VirtualBox unterstützten Formate gefunden.

Es gibt größere Faktoren, die die Leistung beeinflussen, wie z.B.:

• Ihre physischen Geräteeinschränkungen (bei einer Festplatte viel deutlicher spürbar als bei einem Solid-State-Laufwerk … *Warum? * )
• das Expandieren eines dynamisch zugewiesenen virtuellen Laufwerks (Schreibvorgänge sind langsamer, wenn die virtuelle Festplatte expandiert, aber sobald sie groß genug ist, sollte das Expandieren weniger passieren)
• die Virtualisierungstechnologie Hardware vs. Software ; Hardwarevirtualisierung hilft VirtualBox und verbessert die Geschwindigkeit von virtuellen Betriebssystemen)
• die Tatsache, dass Sie ein virtuelles Betriebssystem ausführen. Die Leistung ist aufgrund des Virtualisierungs-Overheads immer langsamer als die Ausführung eines Betriebssystems auf dem Host.

Ich verwende immer VDI, da es das native Format von VirtualBox ist; die Verwendung eines VMDK (VMWare-Format) erhöht jedoch die Kompatibilität mit anderer Software für virtuelle Maschinen.

VirtualBox läuft gut unter Ubuntu, wenn also das Ziel die Windows/Ubuntu-Interoperabilität ist, wäre VDI eine perfekt gültige Wahl.

Beide Formate werden Ihre Anforderungen erfüllen.

Was die beiden anderen angeht, so ist VHD ein von Microsoft entwickeltes Format und HDD ein von Apple entwickeltes Format; beide sind proprietär lizenziert, so dass die plattformübergreifende Unterstützung eingeschränkt ist; ich würde sie nicht empfehlen.

Mpack, erklärt hier einen wesentlichen Leistungsunterschied zwischen VHD und VDI:

Nachdem ich mich kürzlich mit dem VHD-Format beschäftigt habe, würde ich erwarten, dass es zumindest einen kleinen Unterschied zu Gunsten der VDIs gibt, der sich am deutlichsten bemerkbar macht, wenn man Gleiches mit Gleichem vergleicht, d.h. einen optimierten VDI vs. optimierten VHD. Der Grund dafür ist, dass beim dynamischen VHD-Format diese “Bitmap”-Sektoren über die ganze Platte verstreut sind. Jedes Mal, wenn Sie einen Sektor innerhalb eines Blocks ändern, müssen diese Bitmap-Blöcke möglicherweise auch aktualisiert und geschrieben werden, was zusätzliche Such-, Lese- und Schreibvorgänge erfordert. Diese Bitmap-Sektoren müssen auch übersprungen werden, wenn aufeinanderfolgende Cluster von einem Laufwerksabbild gelesen werden - mehr Suchvorgänge. Das VDI-Format hat diesen Overhead nicht, insbesondere dann nicht, wenn die VDI optimiert wurde (Blöcke auf der virtuellen Platte in LBA-Reihenfolge sortiert).

Alle meine Bemerkungen gelten für das dynamische VHD-Format im Vergleich zu dynamischem VDI. Leistungstests auf virtuellen Platten fester Größe sind sinnlos, da dann beide Formate gleich sind (nur ein einfaches Abbild einer Platte), sie haben nur unterschiedliche Header darauf. https://forums.virtualbox.org/viewtopic.php?f=1&t=22688

Ich weiß nicht, ob die Verwendung von vmdk es Ihnen ermöglichen würde, eine in VirtualBox erstellte virtuelle Maschine transparent in VMware auszuführen oder nicht. Es könnte. Eine universellere Option könnte jedoch sein, die VirtualBox-Datei/Exportfunktion zu verwenden, um eine “Open Virtualization Appliance”- .ova-Datei zu erstellen, die dann in VMware importiert werden kann. Mit diesem Ansatz können Sie auf jedes Virtualisierungssystem portieren, das .ova unterstützt, ohne sich darum zu kümmern, welches Festplatten-Image-Format Sie in VirtualBox verwenden.

Wenn Sie in regelmäßigen Abständen, z.B. jeden Tag, aus derselben VM exportieren müssen, könnte das eine Qual sein. Aber wenn Sie nur gelegentlich auf eine andere Technologie umsteigen, sollte das in Ordnung sein.

Wenn Sie bereits eine .vdi-Datei haben, können Sie testen, ob dies funktioniert, ohne eine neue virtuelle Maschine erstellen zu müssen. Exportieren Sie sie in eine .ova-Datei und versuchen Sie dann, sie mit vmware zu importieren.

Es hängt auch davon ab, wie Sie die virtuelle Festplatte verwenden wollen. Nicht jede VM möchte eine einzelne Partition auf einer einzelnen Festplatte.

VDI scheint mehr Optionen zu bieten (bei Verwendung mit VirtualBox), aber sobald man VirtualBox aus dem Spiel nimmt, wird die Unterstützung für VDI etwas wackelig (ab Ende 2014).

Meine Lösungen müssen beispielsweise maximale plattformübergreifende Unterstützung bieten. Das Einbinden einer VDI (wie z.B. eines Loopback-Gerätes) unter Linux oder Windows 7 ist schwieriger und fehleranfälliger, als Sie vielleicht erwarten. Fast so, als hätte die VDI zu viele Funktionen, was es schwierig macht, vollständig konforme Dienstprogramme zu erstellen, die auf ihr arbeiten können.

VMDK ist einfach weniger schmerzlos IMHO, wenn es mit jeder VM auf jeder Workstation funktionieren soll, wenn es dreimal gleichzeitig auf andere Systeme im Netzwerk geklont werden soll und wenn es ohne den Start einer VM-Instanz geöffnet werden soll.

Obwohl ich VirtualBox zu 90% der Zeit verwende, haben mich die wenigen Male, in denen meine Festplatten in bestimmten Workflows unzugänglich werden, dazu veranlasst, VMDK für steckbare/gemeinsam genutzte Dateisysteme zu bevorzugen.

Disk-Image-Dateien befinden sich auf dem Host-System und werden von den Gastsystemen als Festplatten mit einer bestimmten Geometrie angesehen. Wenn ein Gastbetriebssystem von einer Festplatte liest oder auf eine Festplatte schreibt, leitet VirtualBox die Anforderung an die Image-Datei um.

Wie ein physischer Datenträger hat ein virtueller Datenträger eine Größe (Kapazität), die bei der Erstellung der Image-Datei angegeben werden muss. Im Gegensatz zu einem physischen Datenträger ermöglicht VirtualBox jedoch die Erweiterung einer Image-Datei nach der Erstellung, auch wenn sie bereits Daten enthält; VirtualBox unterstützt vier Varianten von Disk-Image-Dateien:

VDI: Normalerweise verwendet VirtualBox ein eigenes Containerformat für Gastfestplatten - Virtual Disk Image (VDI)-Dateien. Insbesondere wird dieses Format verwendet, wenn Sie eine neue virtuelle Maschine mit einer neuen Festplatte erstellen.

VMDK:VirtualBox unterstützt auch vollständig das beliebte und offene VMDK-Containerformat, das von vielen anderen Virtualisierungsprodukten, insbesondere von VMware, verwendet wird. [25]

VHD:VirtualBox unterstützt auch das von Microsoft verwendete VHD-Format vollständig.

Image-Dateien von Parallels Version 2 (HDD-Format) werden ebenfalls unterstützt.[26] Mangels Dokumentation des Formats werden neuere Formate (3 und 4) nicht unterstützt. Sie können solche Bilddateien jedoch mit den von Parallels bereitgestellten Tools in das Format der Version 2 konvertieren.

Ein guter Grund für mich, vmdk zu verwenden, ist, daß Virtualbox (zumindest bis v4.1), das das VDI-Format verwendet, mit der Zeit die Tendenz hat, den gesamten zugewiesenen Plattenplatz zu füllen, obwohl die interne Nutzung der virtuellen Platte noch immer viel geringer ist. Mit Virtualbox, die vmdk-Platten verwendet, scheint dies weniger ein Problem zu sein.

Aber ich spreche von Jahren Betriebszeit. Dies ist vielleicht kein Problem, auf das viele Leute stoßen.

Sieht so aus, als ob die Verwendung von VDI es ermöglicht, die Plattendatei auf ihre tatsächliche Größe zu trimmen VirtualBox und SSD unterstützen den TRIM-Befehl

Ich habe gerade ein rohes VMDK migriert, das auf eine Partition eines Transcend SSD370 128 GB auf ein Samsung Pro 850 512 GB abgebildet wurde.

Offenbar ist VMDK viel schneller als VDI. Ich verstehe nicht warum, vielleicht habe ich irgendwo einen Fehler gemacht.

Ich habe das VMDK über den Virtual Media Manager auf den 850 kopiert. Einmal als VDI, einmal als VMDK.

Dann ließ ich hdparm -tT --direct /dev/sda auf den Bildern laufen. Für jeden der “Läufe” ersetzte ich die “Maschine -> Einstellungen -> Speicher -> Controller SATA -> ImageFile.xxx”. Die Rohpartition auf SSD370 wurde durch eine VMDK-Datei definiert, es handelt sich also nicht wirklich um ein Image.

Dies sind die Ergebnisse:

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

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

Ich weiß nicht wirklich, wie ich das interpretieren soll, vielleicht möchte jemand einen Kommentar dazu hinterlassen. Ich habe dann den VMDK gewählt.

VDI ist viel einfacher zu komprimieren, wenn die VM zu groß wird.

Vor langer Zeit führte ich einen Test durch, bei dem ich dynamische vdi in dynamische vhd konvertierte, nur um Geschwindigkeit und Dateigrößen zu testen.

Erinnern Sie sich, dass es sich um eine unveränderliche, saubere Windows-Gast-OS-Installation mit einigen Anwendungen handelte, erinnern Sie sich, dass ich für meinen Test ein Format in ein anderes konvertierte, so dass beide das exakt gleiche Bild haben sollten, wie beim Klonen.

Bei einer Plattengröße von 64GiB betrug die VDI-Dateigröße etwa 18GiB, während die Dateigröße von VHD etwa 22GiB betrug.

Ich erinnere mich, daß ich diese beiden Dinge gesehen habe:

1. Die Bootzeit war signifikant anders, wenn ich mich nicht daran erinnere, daß schlechtes vhd 1,6 mal schneller war als VDI
2. VHD war viel größer als VDI, etwa 4GiB Gigabyte größer als ein 18GiB, also 1,2 mal größer.

Das ist lange her, und der Test wurde auf einer Festplatte durchgeführt, aber ich stelle sicher, daß beide Dateien defragmentiert waren und nebeneinander auf dem schnellen Teil der Platte lagen.

Ich hoffe, daß jemand echte SSD-Tests durchführen kann, aber ich habe das Gefühl, daß VHD schneller (und größer) ist als VDI.

Nur ein Tip: VHD/VHDX kann direkt auf jedem Windows 7 und höher mit dem Kommandozeilentool DiskPart komprimiert werden, für VDI wird ein externes Tool CloneVDI benötigt.

Tut mir leid, dass ich VMDK nicht getestet habe, ich wusste nicht, wie man es komprimieren kann, ohne seine UUID (die Platten-UUID) zu ändern, denken Sie daran, dass VBOX-Kommando-Tools es immer bei jedem Klon ändern, egal welches Format Sie verwenden.