winfried-hh
Goto Top

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:

screenshot

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:

screenshot2

Schöne Grüße von der Elbe
Winfried

Content-Key: 352542

Url: https://administrator.de/contentid/352542

Ausgedruckt am: 19.03.2024 um 06:03 Uhr

Mitglied: GuentherH
GuentherH 23.10.2017 um 09:16:34 Uhr
Goto Top
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
Mitglied: Winfried-HH
Winfried-HH 23.10.2017 um 09:20:22 Uhr
Goto Top
Zitat von @GuentherH:

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

screenshot3
Mitglied: Clijsters
Clijsters 23.10.2017 um 09:36:28 Uhr
Goto Top
Zitat aus
Get-Help Optimize-VHD

DESCRIPTION
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
Mitglied: Winfried-HH
Winfried-HH 23.10.2017 um 09:59:28 Uhr
Goto Top
Zitat von @Clijsters:

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?
Mitglied: Clijsters
Clijsters 23.10.2017 um 11:28:31 Uhr
Goto Top
Hallo Winfried-HH,

Die VM sollte heruntergefahren sein und die VHD darf nicht auf dem lokalen System gemounted sein.

Beste Gruesse
Dominique
Mitglied: Winfried-HH
Winfried-HH 23.10.2017 um 13:04:27 Uhr
Goto Top
Zitat von @Clijsters:

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?
Mitglied: colinardo
Lösung colinardo 23.10.2017 aktualisiert um 13:10:24 Uhr
Goto Top
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
Mitglied: Winfried-HH
Winfried-HH 23.10.2017 um 14:54:04 Uhr
Goto Top
Zitat von @colinardo:

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?
Mitglied: colinardo
colinardo 23.10.2017 aktualisiert um 19:26:05 Uhr
Goto Top
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.
Mitglied: Winfried-HH
Winfried-HH 23.10.2017 um 19:41:40 Uhr
Goto Top
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.

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?
Mitglied: colinardo
colinardo 23.10.2017 aktualisiert um 20:47:27 Uhr
Goto Top
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 face-wink?) 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.
Mitglied: Winfried-HH
Winfried-HH 23.10.2017 aktualisiert um 21:55:24 Uhr
Goto Top
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 face-wink?)

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 ...
Mitglied: Winfried-HH
Winfried-HH 24.10.2017 aktualisiert um 07:18:35 Uhr
Goto Top
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 face-wink?) 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%:

screenshot4

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:

screenshot5

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?
Mitglied: colinardo
colinardo 24.10.2017 aktualisiert um 07:41:51 Uhr
Goto Top
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.
Mitglied: Winfried-HH
Winfried-HH 24.10.2017 aktualisiert um 08:58:13 Uhr
Goto Top
Zitat von @colinardo:

Vor dem Vorgang hättest du alle Snapshots löschen oder zusammenführen müssen!

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 ...
Mitglied: Clijsters
Clijsters 24.10.2017 um 09:58:39 Uhr
Goto Top
Ich hoffe, dass der einzige Grund für das Entstehen der AVHDX-Dateien die nächtliche Datensicherung war ...
Womit sichert ihr denn?
Mitglied: Winfried-HH
Winfried-HH 24.10.2017 um 10:22:52 Uhr
Goto Top
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
Mitglied: java667
java667 24.10.2017 um 11:52:41 Uhr
Goto Top
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.
Mitglied: Winfried-HH
Winfried-HH 24.10.2017 um 17:48:42 Uhr
Goto Top
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!

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.
Mitglied: Winfried-HH
Winfried-HH 24.10.2017 aktualisiert um 18:01:55 Uhr
Goto Top
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 ...

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.
Mitglied: Winfried-HH
Winfried-HH 25.10.2017 um 09:15:41 Uhr
Goto Top
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.

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.
Mitglied: colinardo
Lösung colinardo 25.10.2017 aktualisiert um 09:26:00 Uhr
Goto Top
Zitat von @Winfried-HH:

Heute nacht um 4 Uhr, nach 20 Stunden Laufzeit, ist er fertig geworden.
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).
Mitglied: Winfried-HH
Winfried-HH 25.10.2017 aktualisiert um 14:40:31 Uhr
Goto Top
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 ...
Mitglied: colinardo
colinardo 25.10.2017 aktualisiert um 16:35:52 Uhr
Goto Top
Werf mal dban an dann weißt du was ich meine.
Bei sdelete und VMs ist das aber normal.
Mitglied: Winfried-HH
Winfried-HH 26.10.2017 um 15:55:27 Uhr
Goto Top
Kleine Ergänzungsfrage: Kann man eigentlich VHDX-Dateien mit irgendeinem Programm auch unter Windows 7 öffnen / mounten?
Mitglied: colinardo
Lösung colinardo 26.10.2017 aktualisiert um 17:27:04 Uhr
Goto Top
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.
https://www.isobuster.com/isobuster.php
usw.