Welches Disk-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 undokumentiert Unterstützung für
  • QCOW -
  • QED

^{_{Quelle: Oracle ® VM VirtualBox® Benutzerhandbuch " Kapitel 5. Virtueller Speicher " 5.2. Disk-Image-Dateien (VDI, VMDK, VHD, HDD)}}

Beantwortung Ihrer Überlegungen

• nutzen zu können, dynamische Größenanpassung

VDI, VMDK und VHD, unterstützen alle dynamisch zugewiesenen Speicher. VMDK verfügt über eine zusätzliche Möglichkeit, die Speicherdatei in Dateien mit jeweils weniger als 2 GB aufzuteilen, was nützlich ist, wenn Ihr Dateisystem über ein kleines Dateigrößenlimit verfügt.

HDD, QCOW, und QED muss dynamisch zugewiesen werden, wenn sie in VirtualBox erstellt werden.

• Schnappschüsse haben können

VirtualBox unterstützt Snapshotting von alle sechs Formate.

• in der Lage sein, um meine virtuellen Maschine zu einem anderen Betriebssystem oder auch ein anderes gratis-Virtualisierungs-Lösung, die mit minimalem Aufwand (wahrscheinlich etwas, das würde gut laufen auf Ubuntu).

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

VMDK wird von und für VMware entwickelt, aber auch VirtualBox und QEMU (eine andere gängige Virtualisierungssoftware) unterstützen es. Dieses Format ist möglicherweise die beste Wahl für Sie, 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, VirtualBox unterstützt VHDX jedoch nicht.

HDD - ist ein format für Parallels. Parallels ist auf Virtualisierung für macOS spezialisiert. Dies ist wahrscheinlich nicht für Sie geeignet, insbesondere wenn man bedenkt, dass VirtualBox nur eine alte Version des HDD-Formats unterstützt.

QCOW ist die alte Originalversion des qcow-Formats. Es wurde durch qcow2 ersetzt, was VirtualBox nicht tut Unterstützung.

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

• Leistung

Jedes der Formate kann aufgrund der Abstraktion des Blockspeichers durch das Format 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 zum Beispiel:

• Ihr physisches Gerät einschränkungen (viel deutlicher auf einer Festplatte als ein [[135]}Solid-State-Laufwerk... Warum?)
• erweitern eines dynamisch zugewiesenen virtuellen Laufwerks (Schreibvorgänge sind langsamer, wenn die virtuelle Festplatte erweitert wird, aber sobald sie groß genug ist, sollte die Erweiterung weniger erfolgen)
• Virtualisierungstechnologie (Hardware vs. Software; Hardware-Virtualisierung hilft VirtualBox und verbessert die Geschwindigkeit virtueller Betriebssysteme)
• die Tatsache, dass Sie führen Sie ein virtuelles Betriebssystem aus. Die Leistung ist aufgrund des Virtualisierungsaufwands immer langsamer als das Ausführen 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 wird auf Ubuntu gut laufen, also wenn das Ziel Windows/Ubuntu Interoperabilität ist, wäre VDI eine vollkommen gültige Wahl.

Beide Formate erfüllen Ihre Anforderungen.

Wie für die anderen beiden, VHD ist ein von Microsoft entwickeltes Format, und HDD ist ein von Apple entwickeltes Format; Dies sind beide proprietär lizenziert, also plattformübergreifende Unterstützung einschränken; Ich würde sie nicht empfehlen.

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

Nachdem ich kürzlich das VHD-Format studiert habe, würde ich erwarten, dass es zumindest einen kleinen Unterschied in den VDIs-Werten gibt, der am auffälligsten ist, wenn Sie like mit like vergleichen, dh ein optimiertes VDI vs optimiertes VHD. Der Grund dafür ist, dass im dynamischen VHD-Format diese "Bitmap" - Sektoren auf der gesamten Festplatte verteilt sind. Jedes Mal, wenn Sie einen Sektor innerhalb eines Blocks ändern, müssen diese Bitmap-Blöcke möglicherweise aktualisiert werden und geschrieben auch mit extra sucht, liest und schreibt. Diese Bitmap-Sektoren müssen auch übersprungen werden, wenn aufeinanderfolgende Cluster aus einem Laufwerksbild gelesen werden - genauer gesagt. Das VDI-Format hat diese Overheads nicht, insbesondere wenn das VDI optimiert wurde (Blöcke auf der virtuellen Festplatte in LBA-Reihenfolge sortiert).

Alle meine Kommentare gelten für das dynamische VHD-Format vs dynamisches VDI. Leistungstests auf virtuellen Festplatten fester Größe sind sinnlos, da beide Formate dann gleich sind (nur eine ebene image einer Festplatte), sie haben nur verschiedene Header auf ihnen.

Https://forums.virtualbox.org/viewtopic.php?f=1&t=22688

Ich weiß nicht, ob Sie mit vmdk eine in VirtualBox in VMware erstellte virtuelle Maschine transparent ausführen können oder nicht. Es könnte. Eine universellere Option könnte jedoch die Verwendung der VirtualBox-Datei/Exportfunktion sein, um eine "Open Virtualization Appliance" zu erstellen .ova-Datei, die dann in VMware importiert werden kann. Mit diesem Ansatz können Sie auf jedes Virtualisierungssystem portieren, das unterstützt wird .ova ohne sich darum zu kümmern, welches Disk-Image-Format Sie in VirtualBox verwenden.

Wenn Sie exportieren müssen von der gleichen VM in regelmäßigen Abständen, z.B. jeden Tag, das könnte ein Schmerz sein. Wenn Sie jedoch nur gelegentlich zu einer anderen Technologie wechseln, sollte dies in Ordnung sein.

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

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

VDI scheint mehr Optionen zu haben (bei Verwendung mit VirtualBox), aber sobald Sie VirtualBox aus dem Bild nehmen, wird die Unterstützung für VDI etwas wackelig (ab Ende 2014).

Zum Beispiel müssen meine Lösungen maximale plattformübergreifende Unterstützung haben. Das Mounten eines VDI (z. B. eines Loopback-Geräts) unter Linux oder Windows 7 ist schwieriger und fehlerhafter als erwartet. Fast wie der VDI hat zu viele Funktionen, was es schwierig macht, vollständig konforme Dienstprogramme zu erstellen, die damit arbeiten können.

VMDK ist meiner Meinung nach weniger schmerzlos, wenn Sie möchten, dass es mit einer VM auf einer Workstation funktioniert, wenn Sie es dreimal gleichzeitig auf andere Systeme im Netzwerk klonen möchten und wenn Sie es öffnen möchten, ohne eine VM-Instanz zu starten.

Obwohl ich VirtualBox 90% der Zeit verwende, werden meine Festplatten in bestimmten Fällen nicht mehr erreichbar workflows haben mich dazu gebracht, VMDK für steckbare / gemeinsam genutzte Dateisysteme zu bevorzugen.

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

Wie eine physische Festplatte hat eine virtuelle Festplatte eine Größe (Kapazität), die beim Erstellen der Image-Datei angegeben werden muss. Im Gegensatz zu einer physischen Festplatte können Sie mit VirtualBox jedoch eine Image-Datei nach der Erstellung erweitern, auch wenn bereits Daten vorhanden sind; VirtualBox unterstützt vier Varianten von Disk-Image-Dateien:

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

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

VHD: VirtualBox unterstützt auch die VHD-format von Microsoft verwendet.

Bilddateien der Parallels Version 2 (HDD-Format) werden ebenfalls unterstützt.[26] Aus Mangel an 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 Version 2-Format konvertieren.

Sieht so aus, als ob die Verwendung von VDI es ermöglicht, die Disk-Datei auf ihre tatsächliche Größe zu trimmen VirtualBox und SSD TRIM-Befehlsunterstützung

Ein guter Grund für mich, vmdk zu verwenden, ist, dass Virtualbox (zumindest bis v4.1), die das VDI-Format verwendet, im Laufe der Zeit dazu neigt, den vollständig zugewiesenen Speicherplatz zu füllen, obwohl die interne Auslastung der virtuellen Festplatte noch viel geringer ist. Mit Virtualbox mit vmdk-Festplatten scheint dies weniger ein Problem zu sein.

Aber ich spreche von Jahren Betriebszeit. Dies ist möglicherweise kein Problem, auf das viele Menschen stoßen.

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

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

Anscheinend 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 das Gerät kopiert. Einmal als VDI, einmal als VMDK.

Dann lief ich hdparm -tT --direct /dev/sda auf den Bildern. Für jeden der "Läufe" wechselte ich zu " Maschine - > Einstellungen - > Speicher - > Controller SATA - > ImageFile.xxx". Die Raw-Partition auf SSD370 wurde durch eine VMDK-Datei definiert, daher handelt es sich 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ß wirklich nicht, wie diese zu interpretieren, vielleicht jemand will, um einen Kommentar auf es. Ich wählte die VMDK dann.

Vor langer Zeit habe ich einen Test durchgeführt, der dynamische VDI in dynamische VHD konvertiert, nur um Geschwindigkeit und Dateigrößen zu testen.

Erinnere mich, es war ein inmutable Windows-Gast ein sauberes Betriebssystem zu installieren mit einige apps, denken Sie daran, für meinen test habe ich konvertieren von einem format in ein anderes, so sind beide suposed zu haben, die exactr gleiche Bild, wie zu tun Klonen.

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

Ich kann mich erinnern, dass ich die beiden gesehen habe Dingen:

1. Boot-Zeit war deutlich anders, wenn ich mich nicht erinnern, schlechte VHD war 1,6 mal schneller als VDI
2. VHD größe war viel größer als VDI, arround 4GiB gigabyte größer über eine 18GiB, so 1,2 mal größer.

Das war vor langer Zeit und Test wurde auf einer Festplatte durchgeführt, aber ich stelle sicher, dass beide Dateien defragmentiert und nebeneinander auf dem schnellen Teil der Festplatte.

Hoffe, jemand kann echte SSD-Tests durchführen, aber mein Gefühl ist, dass VHD schneller (und größer) ist) als VDI.

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

Entschuldigung, ich habe VMDK nicht getestet, ich wusste nicht, wie ich es komprimieren sollte, ohne seine UUID (die UUID der Festplatte) zu ändern, denken Sie daran, dass die VBOX-Befehlstools es immer bei jedem Klon ändern, egal welches Format Sie verwenden.