26
Vhdx-Datei viel größer als Inhalt der Festplatte - wie schrumpfen?
Hallo in die Runde!
Mittlerweile läuft unser neuer, virtueller Schülerserver so wie er soll. Nun habe ich den virtuellen Server einmal heruntergefahren und wollte vom Host die Virtuelle Maschine einmal in diesem quasi neuen Zustand auf einen externen Datenträger sichern. Dabei fiel mir auf, dass die VHDX-Datei der Datenplatte des virtuellen Servers (Server 2016 Standard) 430 GB groß ist. Laut Windows enthält die Platte aber nur knapp 90 GB Daten:
Weiß jemand, wie man die VHDX-Datei auf die tatsächliche Größe herunterschrumpfen kann? Ich möchte ungern schon wieder unseren Dienstleister damit beauftragen, das kostet immer gleich Kohle. Mit dem Hyper-V-Manager habe ich bisher aber gar keine Erfahrung und will natürlich nichts kaputt machen.
Hier die Daten von Get-VHD:
Schöne Grüße von der Elbe
Winfried
Mittlerweile läuft unser neuer, virtueller Schülerserver so wie er soll. Nun habe ich den virtuellen Server einmal heruntergefahren und wollte vom Host die Virtuelle Maschine einmal in diesem quasi neuen Zustand auf einen externen Datenträger sichern. Dabei fiel mir auf, dass die VHDX-Datei der Datenplatte des virtuellen Servers (Server 2016 Standard) 430 GB groß ist. Laut Windows enthält die Platte aber nur knapp 90 GB Daten:
Weiß jemand, wie man die VHDX-Datei auf die tatsächliche Größe herunterschrumpfen kann? Ich möchte ungern schon wieder unseren Dienstleister damit beauftragen, das kostet immer gleich Kohle. Mit dem Hyper-V-Manager habe ich bisher aber gar keine Erfahrung und will natürlich nichts kaputt machen.
Hier die Daten von Get-VHD:
Schöne Grüße von der Elbe
Winfried
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: 352542
Url: https://administrator.de/contentid/352542
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
26 Kommentare
Neuester Kommentar
Ich möchte ungern schon wieder unseren Dienstleister damit beauftragen, das kostet immer gleich Kohle.
Aber der Dienstleister könnt dir erklären was es mit einer dynamischen Festplatte auf sich hat. Überprüfe doch einmal im Explorer des Host wie groß die Datei tatscählich ist.
LG Günther
Zitat von @GuentherH:
Aber der Dienstleister könnt dir erklären was es mit einer dynamischen Festplatte auf sich hat.
Aber der Dienstleister könnt dir erklären was es mit einer dynamischen Festplatte auf sich hat.
Aber als Schule sind unsere Finanzmittel begrenzt. Wir dürfen mit dem Gesamtauftrag nicht über 5000 Euro kommen, sonst steigt uns der Träger aufs Dach!
Überprüfe doch einmal im Explorer des Host wie groß die Datei tatscählich ist.
Hatte ich doch schon geschrieben: 430 GB
Zitat aus
Beste Gruesse
Dominique
Get-Help Optimize-VHDDESCRIPTION
The Optimize-VHD cmdlet optimizes the allocation of space in or more virtual hard disk files, except for fixed virtual hard disks. The Compact
operation is used to optimize the files. This operation reclaims unused blocks as well as rearranges the blocks to be more efficiently packed,
which reduces the size of a virtual hard disk file.
To use Optimize-VHD, the virtual hard disk must not be attached or must be attached in read-only mode.
The compact operation can succeed without reducing the file size, if no optimization is possible.
The Optimize-VHD cmdlet optimizes the allocation of space in or more virtual hard disk files, except for fixed virtual hard disks. The Compact
operation is used to optimize the files. This operation reclaims unused blocks as well as rearranges the blocks to be more efficiently packed,
which reduces the size of a virtual hard disk file.
To use Optimize-VHD, the virtual hard disk must not be attached or must be attached in read-only mode.
The compact operation can succeed without reducing the file size, if no optimization is possible.
Beste Gruesse
Dominique
Zitat von @Clijsters:
To use Optimize-VHD, the virtual hard disk must not be attached or must be attached in read-only mode.
To use Optimize-VHD, the virtual hard disk must not be attached or must be attached in read-only mode.
Was heißt in dem Fall "not be attached"? Darf sie keiner virtuellen Maschine zugeordnet sein? Oder reicht es, wenn die virtuelle Maschine aus ist?
Hallo Winfried-HH,
Die VM sollte heruntergefahren sein und die VHD darf nicht auf dem lokalen System gemounted sein.
Beste Gruesse
Dominique
Die VM sollte heruntergefahren sein und die VHD darf nicht auf dem lokalen System gemounted sein.
Beste Gruesse
Dominique
Zitat von @Clijsters:
Die VM sollte heruntergefahren sein und die VHD darf nicht auf dem lokalen System gemounted sein.
Die VM sollte heruntergefahren sein und die VHD darf nicht auf dem lokalen System gemounted sein.
Ok, das habe ich jetzt gemacht ... aber viel gebracht hat es nicht, gerade mal von 530 auf 415 GB runter.
Wenn ich die englischsprachigen Infos richtig verstanden habe, werden durch dieses "Optimieren" lediglich Bytes mit dem Wert Null aus der VHDX-Datei entfernt. Aber wenn ich unter Windows etwas lösche (selbst wenn ich den Papierkorb leere), ist es ja nicht von der Festplatte verschwunden. Also gibt es vermutlich auch kaum Nullwerte, die entfernt werden können. Die Frage, wie ich die VHDX-Datei kleiner bekomme, ist also allein mit der Optimierung wohl nicht zu beantworten.
Hat jemand weitere Ideen?
Besorg dir sdelete aus den Sysinternals Tools , das Thema hatten wir hier schonmal
VHD trotz Komprimierung unverändert
Vollkommen zusammengeschrumpft bekommst du eine Platte dieser Größe mit dieser Art aber nie.
Grüße Uwe
VHD trotz Komprimierung unverändert
Vollkommen zusammengeschrumpft bekommst du eine Platte dieser Größe mit dieser Art aber nie.
Grüße Uwe
Zitat von @colinardo:
Besorg dir sdelete aus den Sysinternals Tools , das Thema hatten wir hier schonmal
VHD trotz Komprimierung unverändert
Besorg dir sdelete aus den Sysinternals Tools , das Thema hatten wir hier schonmal
VHD trotz Komprimierung unverändert
Danke für den Tipp.
Verständnisfrage: Warum muss man die Platte dazu im Host mounten? Also warum kann/darf/soll man das sdelete nicht vom virtuellen Server, in dem die Platte ohnehin eingebunden ist, starten?
Zitat von @Winfried-HH:
Verständnisfrage: Warum muss man die Platte dazu im Host mounten? Also warum kann/darf/soll man das sdelete nicht vom virtuellen Server, in dem die Platte ohnehin eingebunden ist, starten?
Der Grund: Wenn du das Tool im Gast startest zwackt(alloziiert) es sich für diesen Zweck denn sämtlichen freien Speicher der virtuellen Platte ab. Das führt dann einerseits dazu daß die VM die Platte wieder vergrößert und Anwendungen/Dienste in der VM deswegen wegen Speichermangels abstürzen könnten.Verständnisfrage: Warum muss man die Platte dazu im Host mounten? Also warum kann/darf/soll man das sdelete nicht vom virtuellen Server, in dem die Platte ohnehin eingebunden ist, starten?
Zitat von @colinardo:
Der Grund: Wenn du das Tool im Gast startest zwackt(alloziiert) es sich für diesen Zweck denn sämtlichen freien Speicher der virtuellen Platte ab. Das führt dann einerseits dazu daß die VM die Platte wieder vergrößert und Anwendungen/Dienste in der VM deswegen wegen Speichermangels abstürzen könnten.
Der Grund: Wenn du das Tool im Gast startest zwackt(alloziiert) es sich für diesen Zweck denn sämtlichen freien Speicher der virtuellen Platte ab. Das führt dann einerseits dazu daß die VM die Platte wieder vergrößert und Anwendungen/Dienste in der VM deswegen wegen Speichermangels abstürzen könnten.
Verstehe ich das richtig, dass das nur dann relevant ist, wenn es um die Platte mit dem Betriebssystem geht? In diesem Fall handelt es sich um eine reine Datenplatte, da sind keine Programme drauf. Muss ich es trotzdem über den Host machen, oder geht das unter den Umständen auch im Gast?
Ja, solange es keine Anwendung gibt die die Platte im ständigen Zugriff hat, also z.B. Datenbankanwendungen etc pp.
Ich sehe aber absolut kein Problem darin das im Host direkt zu machen(oder weißt du etwa nicht wie man eine VHDX mountet
?) so ist man 100% sicher daß es keinen Zugriff gibt, aber wenn du es unbedingt in der VM machen willst, bitte tu dir keinen Zwang an.
Ich sehe aber absolut kein Problem darin das im Host direkt zu machen(oder weißt du etwa nicht wie man eine VHDX mountet
?) so ist man 100% sicher daß es keinen Zugriff gibt, aber wenn du es unbedingt in der VM machen willst, bitte tu dir keinen Zwang an.Zitat von @colinardo:
Ich sehe aber absolut kein Problem darin das im Host direkt zu machen(oder weißt du etwa nicht wie man eine VHDX mountet?)
Ich sehe aber absolut kein Problem darin das im Host direkt zu machen(oder weißt du etwa nicht wie man eine VHDX mountet
?)Naja, im Zweifelsfall geht es sogar mit einem einfachen Doppelklick ;)
so ist man 100% sicher daß es keinen Zugriff gibt, aber wenn du es unbedingt in der VM machen willst, bitte tu dir keinen Zwang an.
Vielleicht liegt es daran, dass ich auf mehreren Seiten, die ich mir angeschaut habe, gelesen habe, dass man Virtuelle Platten nicht außerhalb des Gastes bearbeiten soll, weil der Gast sie anschließend eventuell nicht mehr richtig erkennt. Aber vielleicht habe ich das auch falsch verstanden - es waren englischsprachige Seiten, und mein Englisch ist bekanntlich nicht das beste ...
Zitat von @colinardo:
Ich sehe aber absolut kein Problem darin das im Host direkt zu machen(oder weißt du etwa nicht wie man eine VHDX mountet?) so ist man 100% sicher daß es keinen Zugriff gibt, aber wenn du es unbedingt in der VM machen willst, bitte tu dir keinen Zwang an.
Ich sehe aber absolut kein Problem darin das im Host direkt zu machen(oder weißt du etwa nicht wie man eine VHDX mountet
?) so ist man 100% sicher daß es keinen Zugriff gibt, aber wenn du es unbedingt in der VM machen willst, bitte tu dir keinen Zwang an.Sooooo ... ich habe das gestern abend noch gemacht - wie Du geschrieben hast über den Host. Nun habe ich aber ein Problem. Seit ca. 6 1/2 Stunden steht das Ding bei 100%:
Im Takmanager sieht man, dass Secure File Delete noch läuft, wenn auch nur mit ca. 0,5% Prozessorlast.
Gleichzeitig zeogt der Explorer auf dem gemounteten Laufwerk immer weniger freien Platz an (Am Anfang noch über 900 von 888 GB, jetzt nur noch 411 von 999 GB.
Und ein zweites Problem kommt hinzu: In dem Ordner mit den virtuellen Festplatten sieht es jetzt so aus:
Die AVHDX-Dateien der beiden nicht gemounteten Platten sind von 2 Uhr - das ist der Zeitpunkt, an dem der Host eigentlich eine Systemsicherung auf das NAS erstellt.
Aber die AVHDX-Datei der gemounteten Platte hat die aktuelle Uhrzeit und ist immer noch in Bewegung, sie wächst langsam ...
Muss ich abwarten? Wenn der in der Geschwindigkeit wie bisher bis zur Originalgröße weiterwachsen will, kann das noch Tage dauern. Oder kann ich das CMD-Fenster mit SDELETE64 abbrechen, die Daten.VHDX samt der Daten*.AVHDX löschen und die vorher gesicherte alte Daten.VHDX zurückkopieren?
Und wie bekomme ich die AVHDX-Dateien der anderen Laufwerke wieder weg? Da scheint beim Backup ja etwas nicht sauber gelaufen zu sein, normalerweise werden die hinterher wieder gelöscht. Oder liegt das nur daran, dass diesmal der virtuelle Server im Gegensatz zu sonst nicht läuft?
Vor dem Vorgang hättest du alle Snapshots löschen oder zusammenführen müssen!
Du hast hier jetzt vermutlich die "Mutter"-VHD verändert, das geht natürlich klar in die Hose wenn Snapshots existieren welche die Platte mit einbeziehen.
Du hast hier jetzt vermutlich die "Mutter"-VHD verändert, das geht natürlich klar in die Hose wenn Snapshots existieren welche die Platte mit einbeziehen.
Vor dem Vorgang gab es keine Snapshots...
Wie auch immer: Nach einem Neustart des Hosts wurden die VHDX's wieder zusammengeführt. Und nun habe ich SDELETE64 noch mal gestartet. Ich hoffe, dass der einzige Grund für das Entstehen der AVHDX-Dateien die nächtliche Datensicherung war ...
Ich hoffe, dass der einzige Grund für das Entstehen der AVHDX-Dateien die nächtliche Datensicherung war ...
Womit sichert ihr denn?Zitat von @Clijsters:
Ich hoffe, dass der einzige Grund für das Entstehen der AVHDX-Dateien die nächtliche Datensicherung war ...
Womit sichert ihr denn?An der Stelle mit der eingbauten Lösung von Windows
Falls ich das richtig verstanden habe, geht es doch um keine Systemplatte. Und dort sind keine Programme oder ähnliches installiert. Eine reine Datenplatte also?
Warum erstellst du nicht eine neue Platte, welche nicht dynamisch ist und hängst die an den Server ran. Danach einfach die Daten von D auf E kopieren, VM runterfahren, D-Platte aushängen und VM wieder starten. Danach einfach den Laufwerksbuchstaben von E auf D stellen. Fertig!
Allerdings bitte Vorsicht: Wenn das Programm, dass dort seine Daten ablegt, nicht über den Pfad geht (z.B. D:\Daten) kann das auch in die Hose gehen.
Warum erstellst du nicht eine neue Platte, welche nicht dynamisch ist und hängst die an den Server ran. Danach einfach die Daten von D auf E kopieren, VM runterfahren, D-Platte aushängen und VM wieder starten. Danach einfach den Laufwerksbuchstaben von E auf D stellen. Fertig!
Allerdings bitte Vorsicht: Wenn das Programm, dass dort seine Daten ablegt, nicht über den Pfad geht (z.B. D:\Daten) kann das auch in die Hose gehen.
Zitat von @java667:
Warum erstellst du nicht eine neue Platte, welche nicht dynamisch ist und hängst die an den Server ran. Danach einfach die Daten von D auf E kopieren, VM runterfahren, D-Platte aushängen und VM wieder starten. Danach einfach den Laufwerksbuchstaben von E auf D stellen. Fertig!
Warum erstellst du nicht eine neue Platte, welche nicht dynamisch ist und hängst die an den Server ran. Danach einfach die Daten von D auf E kopieren, VM runterfahren, D-Platte aushängen und VM wieder starten. Danach einfach den Laufwerksbuchstaben von E auf D stellen. Fertig!
Naja, die Freigaben müssten sich selbst wiederherstellen, die sind ja in der Registry gespeichert. Aber die NTFS-Rechte nicht unbedingt. Und XCOPY /O hat letztes Mal nicht zu 100% funktioniert.
Zitat von @Winfried-HH:
Wie auch immer: Nach einem Neustart des Hosts wurden die VHDX's wieder zusammengeführt. Und nun habe ich SDELETE64 noch mal gestartet. Ich hoffe, dass der einzige Grund für das Entstehen der AVHDX-Dateien die nächtliche Datensicherung war ...
Wie auch immer: Nach einem Neustart des Hosts wurden die VHDX's wieder zusammengeführt. Und nun habe ich SDELETE64 noch mal gestartet. Ich hoffe, dass der einzige Grund für das Entstehen der AVHDX-Dateien die nächtliche Datensicherung war ...
So, auch diesmal wird in der Eingabeaufforderung seit mehreren Stunden "Cleaning free space on F:\: 100%" angezeigt und gleichzeitig zeigt der Explorer auf dem gemounteten Laufwerk immer weniger freien Platz an (am Anfang noch über 900 von 888 GB, jetzt nur noch 394 von 999 GB und weiter sinkend). Im Taskmanager ist Secure File Delete mit 12% Prozessorlast aktiv.
Nur AVHDX-Dateien gibt es diesmal nicht, die sind wohl tatsächlich durch das Backup entstanden. aber wenn der Vorgang noch länger als bis 2 Uhr nachts dauert, dann kommt das wohl auch wieder hinzu.
Zitat von @Winfried-HH:
So, auch diesmal wird in der Eingabeaufforderung seit mehreren Stunden "Cleaning free space on F:\: 100%" angezeigt und gleichzeitig zeigt der Explorer auf dem gemounteten Laufwerk immer weniger freien Platz an (am Anfang noch über 900 von 888 GB, jetzt nur noch 394 von 999 GB und weiter sinkend). Im Taskmanager ist Secure File Delete mit 12% Prozessorlast aktiv.
So, auch diesmal wird in der Eingabeaufforderung seit mehreren Stunden "Cleaning free space on F:\: 100%" angezeigt und gleichzeitig zeigt der Explorer auf dem gemounteten Laufwerk immer weniger freien Platz an (am Anfang noch über 900 von 888 GB, jetzt nur noch 394 von 999 GB und weiter sinkend). Im Taskmanager ist Secure File Delete mit 12% Prozessorlast aktiv.
Heute nacht um 4 Uhr, nach 20 Stunden Laufzeit, ist er fertig geworden. Ich war zufällig wach und habe gesehen, dass der freie Speicherplatz des gemounteten Laufwerks bis auf 0 heruntergezählt hat, und dann war er wieder bei 902. Von anderen Programmen (z.B. Eraser) kenne ich das so zwar nicht, aber offenbar gehört das bei SDELETE zum Ausnullen des freien Speichers dazu. Was ist nur blöd finde, ist die Prozentzählung im Eingabeaufforderungsfenster. Denn die stand schon nach zwei Stunden bei 100% - das ist verwirrend.
Wie auch immer, nach dem SDELETE-Vorgang konnte ich die VHDX-Datei mit dem Hyper-V-Manager auf immerhin 126 GB eindampfen. Das ist zwar immer noch mehr, als sie belegten Speicher hat, aber immerhin.
Das ist normal bei der Größe!
Ich war zufällig wach und habe gesehen, dass der freie Speicherplatz des gemounteten Laufwerks bis auf 0 heruntergezählt hat, und dann war er wieder bei 902. Von anderen Programmen (z.B. Eraser) kenne ich das so zwar nicht, aber offenbar gehört das bei SDELETE zum Ausnullen des freien Speichers dazu.
Richtig , das Verhalten ist so korrekt so, da sdelete sich den Speicher alloziiert und erst am Ende wieder frei gibt, denn sonst könnte ja ein Prozess zwischenzeitlich wieder in den freigegebenen Speicher schreiben, was wir ja aber verhindern wollen, deswegen dieses Verhalten.Wie auch immer, nach dem SDELETE-Vorgang konnte ich die VHDX-Datei mit dem Hyper-V-Manager auf immerhin 126 GB eindampfen. Das ist zwar immer noch mehr, als sie belegten Speicher hat, aber immerhin.
Das ist ebenfalls normal (Stichwort MFT).Zitat von @colinardo:
Heute nacht um 4 Uhr, nach 20 Stunden Laufzeit, ist er fertig geworden.
Das ist normal bei der Größe!Wirklich? 900 GB Nullen auf eine Platte zu schreiben, kann doch nicht soo lange dauern. Bei einer Schreibgeschwindigkeit von nicht unrealistischen 60 MB/s sollte das nicht über 4,5 Stunden dauern ...
Werf mal dban an dann weißt du was ich meine.
Bei sdelete und VMs ist das aber normal.
Bei sdelete und VMs ist das aber normal.
Kleine Ergänzungsfrage: Kann man eigentlich VHDX-Dateien mit irgendeinem Programm auch unter Windows 7 öffnen / mounten?
Zitat von @Winfried-HH:
Kleine Ergänzungsfrage: Kann man eigentlich VHDX-Dateien mit irgendeinem Programm auch unter Windows 7 öffnen / mounten?
Out of the box mit Bordmitteln nicht, Windows 7 kennt nur das VHD Format ohne Erweiterung, es gibt aber genügend Alternativen mit denen du sie öffnen kannst wie z.B.Kleine Ergänzungsfrage: Kann man eigentlich VHDX-Dateien mit irgendeinem Programm auch unter Windows 7 öffnen / mounten?
https://www.isobuster.com/isobuster.php
usw.
