3
Differenzierende vhdx Dateien in HyperV Testumgebung für schnelleren Testaufbau weniger Platzverbrauch und geringe SSD Schreibleistung
Puh.. vielleicht hat ja noch einer eine bessere Überschrift die ich übernehmen kann.
Ich habe auf meinem System eine 250GB SSD und eine 2TB HDD verbaut.
Wenn ich umfangreichere Tests mit mehreren Hyper-V Maschinen durchführen möchte, komme ich mit mit den 250GB der SSD nicht weit und nutze immer die HDD für die Virtuellen Maschinen.
Zum einen wegen des Plattenplatzes und zum anderen um die SSD zu schonen.
Im Internet habe ich einen Tipp gefunden den ich bisher noch nicht kannte.
Dabei wird die .vhdx Datei von VM1 ( frisches Serversystem mit Grundinstallation + Updates) auf die SSD verschoben und von nun an nur noch lesend genutzt.
Im Hyper-V Manager erstellt man danach eine neue .vhdx Datei vom Typ "Differenzierung" und legt diese im Ordner "*\vm1\virtual hard disks" mit der Bezeichnung vm1-diff.vhdx ab.
Im nächsten Schritt gibt man die Originaldatei vm1.vhdx auf der SSD als Referenz an.
Ordner sowie Bezeichnung sind natürlich egal, ein bisschen Ordnung sollte aber sein denke ich.
Im nächsten Schritt wird in den Eigenschaften von VM1 die vm1-diff.vhdx als Festplatte ausgewählt und schon startet das System von der SSD und nutzt für zukünftige Daten die vm1-diff.vhdx auf der HDD.
Sofern es sich bei vm2 bis vmxyz um das gleiche Betriebssystem handeln sollte, erstellt man hier z.b. eine vm2-diff.vhdx Datei die sich auf die vm1.vhdx Datei auf der SSD bezieht.
So hat man sehr schnell mehrere Virtuelle Maschinen erstellt die sich die gleiche Basisdatei nutzen und von der schnellen SSD lesen.
Vorteile:
- Auf die SSD wird nur lesend zugegriffen.
- Eine Testumgebung ist schnell aufgebaut
- Geringer Platzverbrauch (allgemein und insbesondere auf der SSD)
- Zumindest für einen gewissen Testzeitraum läuft das System sehr flott - Ist für den Produktivgebrauch vielleicht nur bedingt zu gebrauchen.
Ich vermute mal, dass der ein oder andere das schon kennt und nutzt, für mich war es jedenfalls neu!
Bin auf Euer Pro und Contra gespannt.
Ich habe auf meinem System eine 250GB SSD und eine 2TB HDD verbaut.
Wenn ich umfangreichere Tests mit mehreren Hyper-V Maschinen durchführen möchte, komme ich mit mit den 250GB der SSD nicht weit und nutze immer die HDD für die Virtuellen Maschinen.
Zum einen wegen des Plattenplatzes und zum anderen um die SSD zu schonen.
Im Internet habe ich einen Tipp gefunden den ich bisher noch nicht kannte.
Dabei wird die .vhdx Datei von VM1 ( frisches Serversystem mit Grundinstallation + Updates) auf die SSD verschoben und von nun an nur noch lesend genutzt.
Im Hyper-V Manager erstellt man danach eine neue .vhdx Datei vom Typ "Differenzierung" und legt diese im Ordner "*\vm1\virtual hard disks" mit der Bezeichnung vm1-diff.vhdx ab.
Im nächsten Schritt gibt man die Originaldatei vm1.vhdx auf der SSD als Referenz an.
Ordner sowie Bezeichnung sind natürlich egal, ein bisschen Ordnung sollte aber sein denke ich.
Im nächsten Schritt wird in den Eigenschaften von VM1 die vm1-diff.vhdx als Festplatte ausgewählt und schon startet das System von der SSD und nutzt für zukünftige Daten die vm1-diff.vhdx auf der HDD.
Sofern es sich bei vm2 bis vmxyz um das gleiche Betriebssystem handeln sollte, erstellt man hier z.b. eine vm2-diff.vhdx Datei die sich auf die vm1.vhdx Datei auf der SSD bezieht.
So hat man sehr schnell mehrere Virtuelle Maschinen erstellt die sich die gleiche Basisdatei nutzen und von der schnellen SSD lesen.
Vorteile:
- Auf die SSD wird nur lesend zugegriffen.
- Eine Testumgebung ist schnell aufgebaut
- Geringer Platzverbrauch (allgemein und insbesondere auf der SSD)
- Zumindest für einen gewissen Testzeitraum läuft das System sehr flott - Ist für den Produktivgebrauch vielleicht nur bedingt zu gebrauchen.
Ich vermute mal, dass der ein oder andere das schon kennt und nutzt, für mich war es jedenfalls neu!
Bin auf Euer Pro und Contra gespannt.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 342781
Url: https://administrator.de/contentid/342781
Ausgedruckt am: 23.11.2024 um 11:11 Uhr
3 Kommentare
Neuester Kommentar
Ich habe mal gesehen, dass Leute das sogar produktiv im HyperV verwenden um Speicher für ihre ganzen VMs zu sparen. (Bei sehr vielen VMs ist das ja auch verlockend!)
Ich selbst habe es aber schon geschafft aus versehen die "Original-VHDX" schreibend zu mounten (ein Doppelklick genügt ja). Ohne weiteres zutun sind dann alle darauf aufbauenden VMs hinfällig. Sind dann auch noch Snapshots der VMs im Spiel wird es richtig übel. (Wohl dem, wer Sicherungen hat).
Also am besten per Schreibschutz oder NTFS-Rechte wirklich auf "nur lesen" beschränken ;)
Keine Ahnung ob es da einen Leitpfaden für auf Produktiv-Systeme gibt. Da wäre der Schaden ja enorm. Beim Testsystem zerstört man sich ggf. "nur" die Testumgebung ...
Ich selbst habe es aber schon geschafft aus versehen die "Original-VHDX" schreibend zu mounten (ein Doppelklick genügt ja). Ohne weiteres zutun sind dann alle darauf aufbauenden VMs hinfällig. Sind dann auch noch Snapshots der VMs im Spiel wird es richtig übel. (Wohl dem, wer Sicherungen hat).
Also am besten per Schreibschutz oder NTFS-Rechte wirklich auf "nur lesen" beschränken ;)
Keine Ahnung ob es da einen Leitpfaden für auf Produktiv-Systeme gibt. Da wäre der Schaden ja enorm. Beim Testsystem zerstört man sich ggf. "nur" die Testumgebung ...
OK.
In der c't gab es einen Langzeittest bzgl. dessen.
Brauchst Dir also keine Sorge zu machen. Ich weiß zwar nicht welche SSD Du verwendest, aber beispielsweise eine Samsung 860 Evo hat Du 150.000 TBW Tera byte Written) in 5 Jahren.
In einem meiner Notebook habe ich zwei 500GiB SSDs der Samsung 860 Evo eingebaut.
Diese sind seit einem Jahr aktiv. Auf der ersten SSD sinde es 15,84 TBW und auf der zweiten 9,32 TBW.
Ich habe mittlerweile meine VMs auf der zweiten SSD verschoben.
Gruss Penny
Wenn ich umfangreichere Tests mit mehreren Hyper-V Maschinen durchführen möchte, komme ich mit mit den 250GB der SSD nicht weit und nutze immer die HDD für die Virtuellen Maschinen.
Hm, grade für VMs empfehle ich eine SSD zu verwenden. Muss ja nicht gleich eine 2 TiB SSD sein.Zum einen wegen des Plattenplatzes und zum anderen um die SSD zu schonen.
OK, die Plattenkapazität ist mit 240 GiB etwas wenig. Bezüglich SSD schonen, halte ich für das mittlerweile für einen Mythos.In der c't gab es einen Langzeittest bzgl. dessen.
Brauchst Dir also keine Sorge zu machen. Ich weiß zwar nicht welche SSD Du verwendest, aber beispielsweise eine Samsung 860 Evo hat Du 150.000 TBW Tera byte Written) in 5 Jahren.
In einem meiner Notebook habe ich zwei 500GiB SSDs der Samsung 860 Evo eingebaut.
Diese sind seit einem Jahr aktiv. Auf der ersten SSD sinde es 15,84 TBW und auf der zweiten 9,32 TBW.
Ich habe mittlerweile meine VMs auf der zweiten SSD verschoben.
Im Internet habe ich einen Tipp gefunden den ich bisher noch nicht kannte.
Dabei wird die .vhdx Datei von VM1 ( frisches Serversystem mit Grundinstallation + Updates) auf die SSD verschoben und von nun an nur noch lesend genutzt.
Vorteile:
- Auf die SSD wird nur lesend zugegriffen.
- Eine Testumgebung ist schnell aufgebaut
- Geringer Platzverbrauch (allgemein und insbesondere auf der SSD)
- Zumindest für einen gewissen Testzeitraum läuft das System sehr flott - Ist für den Produktivgebrauch vielleicht nur bedingt zu gebrauchen.
Wie gesagt, bei 100.000 oder gar 150.000 TBW kein Grund die SSD nicht zu nutzen. Im Gegenteil die VMs starten von SSD schneller.Dabei wird die .vhdx Datei von VM1 ( frisches Serversystem mit Grundinstallation + Updates) auf die SSD verschoben und von nun an nur noch lesend genutzt.
Vorteile:
- Auf die SSD wird nur lesend zugegriffen.
- Eine Testumgebung ist schnell aufgebaut
- Geringer Platzverbrauch (allgemein und insbesondere auf der SSD)
- Zumindest für einen gewissen Testzeitraum läuft das System sehr flott - Ist für den Produktivgebrauch vielleicht nur bedingt zu gebrauchen.
Ich vermute mal, dass der ein oder andere das schon kennt und nutzt, für mich war es jedenfalls neu!
Ansonsten ist der Tipp für manche neu. Ich kenne die Funktion schon vom Server 2012.Gruss Penny
Setzen wir ein, allerdings geht es dabei um VHDs mit Nutzdaten, bei denen es sich anbietet.
Für ein Testsystem mag es auch reichen. Für die Konsolidierung produktiver VMs ist es eher nichts.
Denn es verhält sich ja nicht anders als mit Snapshots:
Der Snapshot einer Windows VM ist schnell auf beachtliche Größe angewachsen. Für kurzlebige Testumgebungen mag es reichen, aber die Ersparnis schmilzt durch das Schreib- und Update-Volumen innerhalb von Monaten dahin.
Dazu kommt die erhebliche Einschränkung, das nie mehr vernünftig separieren zu können, wenn die Zustände in den Diffs erhaltenswert sind, wie das bei installierten Systemen der Fall ist. Irgendwann hast du ein virtuelles Netz von z.B. 20 Clients, alle auf einer 20 GB Basis-VHD und mit einer 15 GB Diff-VHD. Es gibt meines Wissens keine Lösung, von den 20x15 GB Diffs wieder runter zu kommen, etwa indem ein Verfahren eine der Diffs mit der Basis vereint und sie gleichzeitig aus den anderen Diffs subtrahiert, damit die wieder differenziell zur neuen Basis sind. Das wäre ein essenzielles Feature, das leider fehlt.
Die sinnvolle Alternative für dieses Szenario ist die VDI-Deduplizierung auf dem Host. Die greift eben auch redundante Vorgänge wie Updates auf allen Maschinen, und du kannst trotzdem von jeder jederzeit eine konsistente VHD herauskopieren, ohne die Basis mitschleppen zu müssen. Auf einem anderen deduplizierenden Host mit gleichartigen VMs ist diese VHD dann wieder genauso schlank unterzubringen. Also größere Platzersparnis und einfachere Handhabung. Mit dem Ausrollen größerer Updates/Upgrades muss man ein wenig aufpassen, damit nicht alle VMs zwischen den Dedup-Zyklen auf einmal aufgeblasen werden. Ein Nachteil - neben der Schreibrate - ist natürlich das Schreibvolumen auf den SSDs. Da man aber überhaupt nur vergleichsweise wenig SSD-Kapazität investiert und die heute ziemlich robust ist, kann man sie m.E. auch dafür "verbraten". Das ist ja mehr eine Notlösung.
Grüße
Richard
Für ein Testsystem mag es auch reichen. Für die Konsolidierung produktiver VMs ist es eher nichts.
Denn es verhält sich ja nicht anders als mit Snapshots:
Der Snapshot einer Windows VM ist schnell auf beachtliche Größe angewachsen. Für kurzlebige Testumgebungen mag es reichen, aber die Ersparnis schmilzt durch das Schreib- und Update-Volumen innerhalb von Monaten dahin.
Dazu kommt die erhebliche Einschränkung, das nie mehr vernünftig separieren zu können, wenn die Zustände in den Diffs erhaltenswert sind, wie das bei installierten Systemen der Fall ist. Irgendwann hast du ein virtuelles Netz von z.B. 20 Clients, alle auf einer 20 GB Basis-VHD und mit einer 15 GB Diff-VHD. Es gibt meines Wissens keine Lösung, von den 20x15 GB Diffs wieder runter zu kommen, etwa indem ein Verfahren eine der Diffs mit der Basis vereint und sie gleichzeitig aus den anderen Diffs subtrahiert, damit die wieder differenziell zur neuen Basis sind. Das wäre ein essenzielles Feature, das leider fehlt.
Die sinnvolle Alternative für dieses Szenario ist die VDI-Deduplizierung auf dem Host. Die greift eben auch redundante Vorgänge wie Updates auf allen Maschinen, und du kannst trotzdem von jeder jederzeit eine konsistente VHD herauskopieren, ohne die Basis mitschleppen zu müssen. Auf einem anderen deduplizierenden Host mit gleichartigen VMs ist diese VHD dann wieder genauso schlank unterzubringen. Also größere Platzersparnis und einfachere Handhabung. Mit dem Ausrollen größerer Updates/Upgrades muss man ein wenig aufpassen, damit nicht alle VMs zwischen den Dedup-Zyklen auf einmal aufgeblasen werden. Ein Nachteil - neben der Schreibrate - ist natürlich das Schreibvolumen auf den SSDs. Da man aber überhaupt nur vergleichsweise wenig SSD-Kapazität investiert und die heute ziemlich robust ist, kann man sie m.E. auch dafür "verbraten". Das ist ja mehr eine Notlösung.
Grüße
Richard
