VHD-Kompression schlägt fehl, Ereignis-ID: 3, 2424869

Dynamische VHD’s sind ein Graus. Zum einen, weil jene der Fragmentation förderlich sind und zweitens, weil sie total langsam sind. Ich mag dynamische Disks generell nicht. In Zeiten knapper Kassen sind jene aber zu Hauf anzutreffen. Und Administratoren, die versuchen, jene im Zaum zu halten. Allseits beliebt: Die Funktion „Komprimieren“. Was nur, wenn das in die Hose geht?

Dann liegt das in aller Regel an den Schattenkopien. Ihr erkennt zunächst im Systemlog einige Einträge mit mehr oder weniger korrekten Meldungen, z.B. Ereignis-ID3:

Das ist Beispielhaft. Ihr entdeckt im Systemlog folgende Meldungen:

Die Schattenkopien von Volume "\?\Volume{a9194bc4-3a01-11e5-867e-b4b52f5b7c9e}" wurden während der Ermittlung abgebrochen, weil eine kritische Steuerungsdatei nicht geöffnet werden konnte.
Der Filter-Manager konnte keine Verbindung mit dem Volume "\Device\HarddiskVolume384" herstellen. Dieses Volume ist erst nach einem Neustart für die Filterung verfügbar. Der letzte Status war "0xc03a001c".
Bei einem Auslagerungsvorgang wurde ein Fehler festgestellt. Betroffen ist Gerät \Device\Harddisk5\DR215.

In den Ereignissen von //Microsoft/Windows/Hyper-V-Hypervisor/Hyper-V-Image-Management-Service werdet Ihr dann doch schlauer:

 

Fehler beim Komprimieren von "PLATTENNAME.vhd". Fehlercode: 2424869

Und da liegt der Hase im Pfeffer. Und wie lautet die Lösung: Ihr habt n Schattenkopien auf der Platte. Löscht die doch einfach. Dann klappt’s auch mit der Kompression. Wie das geht? Gasthütte hochfahren und dann mit administrativer Dosbox innerhalb der Gasthütte genau so:

So schaut Ihr, wie viele und vor allem welche Schattenkopien Ihr drauf habt:

vssadmin list shadows

Und so löscht Ihr sie:

vssadmin delete shadows /all

Das war’s. Viel Spaß. Und nicht vergessen: Budget neu verhandeln…