Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Komprimierung dynamischer Datenträger für virtuelle Maschinen, Windows 10
75 views
Skip to first unread message
Thomas Einzel
Jul 22, 2017, 11:37:41 AM7/22/17
to
Beispiel (real):
vdhx dynamisch 60GB, in der Win10x64pro Vm c: 19,7GB
Datenträgerbereinigung (Admin)
sdelete c: -z
Vm herunterfahren
vdhx im Hyper-V-Manager (auch Win10x64pro) komprimieren -> 41,8GB
Was mit kleinem Aufwand kann man machen, um dynamische Datenträger für
virtuelle Maschinen wieder auf das ca. verwendete Maß zu verkleinern?
(alles private Anwendung, kein RZ)
--
Thomas
vdhx dynamisch 60GB, in der Win10x64pro Vm c: 19,7GB
Datenträgerbereinigung (Admin)
sdelete c: -z
Vm herunterfahren
vdhx im Hyper-V-Manager (auch Win10x64pro) komprimieren -> 41,8GB
Was mit kleinem Aufwand kann man machen, um dynamische Datenträger für
virtuelle Maschinen wieder auf das ca. verwendete Maß zu verkleinern?
(alles private Anwendung, kein RZ)
--
Thomas
Thomas Einzel
Jul 22, 2017, 2:55:50 PM7/22/17
to
Am 22.07.2017 um 17:37 schrieb Thomas Einzel:
> Beispiel (real):
> vdhx dynamisch 60GB, in der Win10x64pro Vm c: 19,7GB
>
> Datenträgerbereinigung (Admin)
> sdelete c: -z
> Vm herunterfahren
> vdhx im Hyper-V-Manager (auch Win10x64pro) komprimieren -> 41,8GB
<Ingrid>
> Beispiel (real):
> vdhx dynamisch 60GB, in der Win10x64pro Vm c: 19,7GB
>
> Datenträgerbereinigung (Admin)
> sdelete c: -z
> Vm herunterfahren
> vdhx im Hyper-V-Manager (auch Win10x64pro) komprimieren -> 41,8GB
vorsorglich nochmal sdelete und danach Komprimierung, nun etwas unter
41GB, aber weniger wird es nicht
</Ingrid>
--
Thomas
Oliver Doll
Jul 22, 2017, 5:09:04 PM7/22/17
to
On 22.07.2017 17:37, Thomas Einzel wrote:
> Was mit kleinem Aufwand kann man machen, um dynamische Datenträger für
> virtuelle Maschinen wieder auf das ca. verwendete Maß zu verkleinern?
Da Du ja wohl offensichtlich (*) TI auf einem USB-Stick hast, folgende Idee:
> Was mit kleinem Aufwand kann man machen, um dynamische Datenträger für
> virtuelle Maschinen wieder auf das ca. verwendete Maß zu verkleinern?
TI in VM von USB booten, 1. dyn Datenträger auf 2. neuen weiteren
klonen. 1.DT entsorgen und 2. DT_Klon als LW verwenden.
--
DuG
Oliver
Michael Logies
Jul 23, 2017, 4:11:41 AM7/23/17
to
Vermutlich ein Ergebnis von Fragmentierung. Nachdem es mir schon `mal
eine VM unter VMWare Player durch dessen Komprimieren völlig zerlegt
hat, bin ich vorsichtiger. Ansonsten:
https://www.windowspro.de/wolfgang-sommergut/vhdx-laufwerke-komprimieren-verkleinern
https://www.windowspro.de/wolfgang-sommergut/vmdk-vhd-virtuelle-festplatten-defragmentieren
eine VM unter VMWare Player durch dessen Komprimieren völlig zerlegt
hat, bin ich vorsichtiger. Ansonsten:
https://www.windowspro.de/wolfgang-sommergut/vhdx-laufwerke-komprimieren-verkleinern
https://www.windowspro.de/wolfgang-sommergut/vmdk-vhd-virtuelle-festplatten-defragmentieren
Thomas Einzel
Jul 23, 2017, 5:11:50 AM7/23/17
to
Am 22.07.2017 um 23:08 schrieb Oliver Doll:
> On 22.07.2017 17:37, Thomas Einzel wrote:
>> Was mit kleinem Aufwand kann man machen, um dynamische Datenträger für
>> virtuelle Maschinen wieder auf das ca. verwendete Maß zu verkleinern?
...
> On 22.07.2017 17:37, Thomas Einzel wrote:
>> Was mit kleinem Aufwand kann man machen, um dynamische Datenträger für
>> virtuelle Maschinen wieder auf das ca. verwendete Maß zu verkleinern?
> TI in VM von USB booten, 1. dyn Datenträger auf 2. neuen weiteren
> klonen. 1.DT entsorgen und 2. DT_Klon als LW verwenden.
Danke, merke ich mir als Option "Notlösung". Für periodisches aufräumen
> klonen. 1.DT entsorgen und 2. DT_Klon als LW verwenden.
ist es mir zu aufwändig.
--
Thomas
Thomas Einzel
Jul 23, 2017, 7:08:41 AM7/23/17
to
Am 23.07.2017 um 10:11 schrieb Michael Logies:
> Vermutlich ein Ergebnis von Fragmentierung.
^^das war es
> Vermutlich ein Ergebnis von Fragmentierung.
> Nachdem es mir schon `mal
> eine VM unter VMWare Player durch dessen Komprimieren völlig zerlegt
> hat, bin ich vorsichtiger. Ansonsten:
...
> eine VM unter VMWare Player durch dessen Komprimieren völlig zerlegt
> hat, bin ich vorsichtiger. Ansonsten:
> https://www.windowspro.de/wolfgang-sommergut/vmdk-vhd-virtuelle-festplatten-defragmentieren
Danke auch für diesen Hinweis, es liegt am _lokalen_ Speicher. Die
virtuellen Datenträger anderer VMs habe ich per iSCSI im NAS, da tritt
dieser Aufbläh-Effekt der vhdx, wie auch im Artikel erwähnt, kaum bis
gar nicht auf. Ich hatte schon überlegt mir eventuell eine etwas größere
SSD für den Hostrechner zu kaufen, jetzt würde ich diese eher in das NAS
für den iSCSI Storage verwenden.
Ich habe nun auf dem Gast defragmentiert, erneut auf dem Gast sdelete -z
laufen lassen und danach bei ausgeschalteter Vm im Hyper-V-Manager
komprimiert: die betreffende vhdx ist jetzt 19,9GB groß und damit
praktisch gleich groß wie C: im Gastsystem - und alles ging mit
Win10x64pro Bordmitteln.
--
Thomas
Thomas Einzel
Jul 23, 2017, 7:32:09 AM7/23/17
to
Am 23.07.2017 um 10:11 schrieb Michael Logies:
> Vermutlich ein Ergebnis von Fragmentierung.
^^das war es
> Nachdem es mir schon `mal
> eine VM unter VMWare Player durch dessen Komprimieren völlig zerlegt
> hat, bin ich vorsichtiger. Ansonsten:
> eine VM unter VMWare Player durch dessen Komprimieren völlig zerlegt
> hat, bin ich vorsichtiger. Ansonsten:
...
> https://www.windowspro.de/wolfgang-sommergut/vmdk-vhd-virtuelle-festplatten-defragmentieren
Danke auch für diesen Hinweis, es liegt am _lokalen_ Speicher. Die
virtuellen Datenträger anderer VMs habe ich per iSCSI im NAS, da tritt
dieser Aufbläh-Effekt der vhdx, wie auch im Artikel erwähnt, kaum bis
gar nicht auf. Ich hatte schon überlegt mir eventuell eine etwas größere
SSD für den Hostrechner zu kaufen, jetzt würde ich diese eher in das NAS
für den iSCSI Storage verwenden.
Ich habe nun auf dem Gast defragmentiert, erneut auf dem Gast sdelete -z
laufen lassen und danach bei ausgeschalteter Vm im Hyper-V-Manager
komprimiert: die betreffende vhdx ist jetzt 19,9GB groß (im Gastsystem
> https://www.windowspro.de/wolfgang-sommergut/vmdk-vhd-virtuelle-festplatten-defragmentieren
Danke auch für diesen Hinweis, es liegt am _lokalen_ Speicher. Die
virtuellen Datenträger anderer VMs habe ich per iSCSI im NAS, da tritt
dieser Aufbläh-Effekt der vhdx, wie auch im Artikel erwähnt, kaum bis
gar nicht auf. Ich hatte schon überlegt mir eventuell eine etwas größere
SSD für den Hostrechner zu kaufen, jetzt würde ich diese eher in das NAS
für den iSCSI Storage verwenden.
Ich habe nun auf dem Gast defragmentiert, erneut auf dem Gast sdelete -z
laufen lassen und danach bei ausgeschalteter Vm im Hyper-V-Manager
nun 14,5GB) - und alles ging mit Win10x64pro Bordmitteln.
--
Thomas
Stefan Kanthak
Jul 23, 2017, 10:58:17 AM7/23/17
to
"Thomas Einzel" <usene...@einzel.de> schrieb:
> Beispiel (real):
> vdhx dynamisch 60GB, in der Win10x64pro Vm c: 19,7GB
>
> Datenträgerbereinigung (Admin)
> sdelete c: -z
Wozu dieser "cargo cult"?
Wieso nicht CIPHER.exe /W %SystemDrive%?
> Vm herunterfahren
> vdhx im Hyper-V-Manager (auch Win10x64pro) komprimieren -> 41,8GB
>
> Was mit kleinem Aufwand kann man machen, um dynamische Datenträger für
> virtuelle Maschinen wieder auf das ca. verwendete Maß zu verkleinern?
Wie waer's mit
Mount-VHD -Path <*.VHD> -NoDriveLetter -ReadOnly
Optimize-VHD -Path <*.VHDX> -Mode=Full
Resize-VHD -Path <*.VHDX> -ToMinimumSize
Dismount-VHD -Path <*.VHD>
Siehe <https://technet.microsoft.com/de-de/library/hh848559.aspx>
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
> Beispiel (real):
> vdhx dynamisch 60GB, in der Win10x64pro Vm c: 19,7GB
>
> Datenträgerbereinigung (Admin)
> sdelete c: -z
Wieso nicht CIPHER.exe /W %SystemDrive%?
> Vm herunterfahren
> vdhx im Hyper-V-Manager (auch Win10x64pro) komprimieren -> 41,8GB
>
> Was mit kleinem Aufwand kann man machen, um dynamische Datenträger für
> virtuelle Maschinen wieder auf das ca. verwendete Maß zu verkleinern?
Mount-VHD -Path <*.VHD> -NoDriveLetter -ReadOnly
Optimize-VHD -Path <*.VHDX> -Mode=Full
Resize-VHD -Path <*.VHDX> -ToMinimumSize
Dismount-VHD -Path <*.VHD>
Siehe <https://technet.microsoft.com/de-de/library/hh848559.aspx>
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Stefan Kanthak
Jul 23, 2017, 10:58:17 AM7/23/17
to
"Oliver Doll" <doll....@gmail.com> schrieb:
AUTSCH!
Das kann Windows^WHyper-V mit den BORDWERKZEUGEN: Convert-VHD ...
Kaputte Bloatware wie dieses TI ist voellig ueberfluessig!
Das kann Windows^WHyper-V mit den BORDWERKZEUGEN: Convert-VHD ...
Kaputte Bloatware wie dieses TI ist voellig ueberfluessig!
Thorsten Albrecht
Jul 24, 2017, 4:55:37 AM7/24/17
to
Thomas Einzel <usene...@einzel.de> wrote:
>Danke auch für diesen Hinweis, es liegt am _lokalen_ Speicher. Die
>virtuellen Datenträger anderer VMs habe ich per iSCSI im NAS, da tritt
>dieser Aufbläh-Effekt der vhdx, wie auch im Artikel erwähnt, kaum bis
>gar nicht auf. Ich hatte schon überlegt mir eventuell eine etwas größere
>SSD für den Hostrechner zu kaufen, jetzt würde ich diese eher in das NAS
>für den iSCSI Storage verwenden.
>
>Ich habe nun auf dem Gast defragmentiert, erneut auf dem Gast sdelete -z
>laufen lassen und danach bei ausgeschalteter Vm im Hyper-V-Manager
>komprimiert: die betreffende vhdx ist jetzt 19,9GB groß (im Gastsystem
>nun 14,5GB) - und alles ging mit Win10x64pro Bordmitteln.
sdelete -z überschreibt den freien Platz einer Festplatte mit Nullen.
>Danke auch für diesen Hinweis, es liegt am _lokalen_ Speicher. Die
>virtuellen Datenträger anderer VMs habe ich per iSCSI im NAS, da tritt
>dieser Aufbläh-Effekt der vhdx, wie auch im Artikel erwähnt, kaum bis
>gar nicht auf. Ich hatte schon überlegt mir eventuell eine etwas größere
>SSD für den Hostrechner zu kaufen, jetzt würde ich diese eher in das NAS
>für den iSCSI Storage verwenden.
>
>Ich habe nun auf dem Gast defragmentiert, erneut auf dem Gast sdelete -z
>laufen lassen und danach bei ausgeschalteter Vm im Hyper-V-Manager
>komprimiert: die betreffende vhdx ist jetzt 19,9GB groß (im Gastsystem
>nun 14,5GB) - und alles ging mit Win10x64pro Bordmitteln.
Wenn Du die Größe einer VHDX dynamisch definierst, ist es doch
logisch, dass der Platzbedarf der VHDX auf dem Hostsystem wächst - sie
wird ja durch die Nullen/den einmal überschriebenen Leerplatz größer,
da sozusagen neuer Platzbedarf angemeldet wird.
Insofern frage ich mich, was Du mit sdelete -z eigentlich am Anfang
überhaupt erreichen wolltest.
Warum der Effekt auf Deinem NAS nicht eintritt, würde mich übrigens
interessieren. Eigentlich sollte das dort genauso laufen wie auf der
lokalen Platte.
BTW Nur zur Info, falls Du das vorhaben solltest: Man kann nicht
Hyper-V und VMware Workstation parallel betreiben, wie ich letzte
Woche leider erkennen musste. Nur entweder oder. Gibt allerdings einen
Workaround mit Modifikation des Bootmanagers.
Thorsten
Claus Reibenstein
Jul 24, 2017, 10:48:06 AM7/24/17
to
Thorsten Albrecht schrieb am 24.07.2017 um 10:55:
> sdelete -z überschreibt den freien Platz einer Festplatte mit Nullen.
> Wenn Du die Größe einer VHDX dynamisch definierst, ist es doch
> logisch, dass der Platzbedarf der VHDX auf dem Hostsystem wächst - sie
> wird ja durch die Nullen/den einmal überschriebenen Leerplatz größer,
> da sozusagen neuer Platzbedarf angemeldet wird.
Vernünftige VM-Systeme wie VirtualBox und VMWare melden bei dynamischen
> sdelete -z überschreibt den freien Platz einer Festplatte mit Nullen.
> Wenn Du die Größe einer VHDX dynamisch definierst, ist es doch
> logisch, dass der Platzbedarf der VHDX auf dem Hostsystem wächst - sie
> wird ja durch die Nullen/den einmal überschriebenen Leerplatz größer,
> da sozusagen neuer Platzbedarf angemeldet wird.
Datenträgern erst dann neuen Platzbedarf an, wenn neue Datenblöcke
geschrieben werden müssen, die nicht nur aus Nullbytes bestehen. Das
Schreiben von reinen Nullen erhöht den Platzbedarf hingegen nicht.
Gruß
Claus
Thomas Einzel
Jul 24, 2017, 11:52:24 AM7/24/17
to
Am 24.07.2017 um 10:55 schrieb Thorsten Albrecht:
...
kaum merkbarer Komprimierung mit dem Hyper-V-Manager. Danach sdelete -z
war Bestandteil von Tipps, die ich gelesen hatte, sdelete behauptet von
sich selbst" -z Zero free space (good for virtual disk
optimization)".
Aber ja, nach den Hinweisen im Thread werde ich das nächste mal die
Prozedur ohne sdelete testen.
Es ist nur für Testergebnisse sehr unpraktisch, mehrere Parameter
gleichzeitig zu ändern, weil man dann nicht weiß, welche der Änderungen
was bewirkt hat.
> Warum der Effekt auf Deinem NAS nicht eintritt, würde mich übrigens
> interessieren. Eigentlich sollte das dort genauso laufen wie auf der
> lokalen Platte.
Das stand im erwähnten link. Weiterhin habe ich den Platz auf dem NAS
für die vhdx nicht per smb gemountet und greife nicht dateiweise zu,
sondern per iSCSI block basierend. Das könnte den Effekt "kaum
fragmentiert" erklären.
--
Thomas
...
> Insofern frage ich mich, was Du mit sdelete -z eigentlich am Anfang
> überhaupt erreichen wolltest.
Nicht am Anfang, sondern nach Datenträgerbereinigung auf dem Gast und
> überhaupt erreichen wolltest.
kaum merkbarer Komprimierung mit dem Hyper-V-Manager. Danach sdelete -z
war Bestandteil von Tipps, die ich gelesen hatte, sdelete behauptet von
sich selbst" -z Zero free space (good for virtual disk
optimization)".
Aber ja, nach den Hinweisen im Thread werde ich das nächste mal die
Prozedur ohne sdelete testen.
Es ist nur für Testergebnisse sehr unpraktisch, mehrere Parameter
gleichzeitig zu ändern, weil man dann nicht weiß, welche der Änderungen
was bewirkt hat.
> Warum der Effekt auf Deinem NAS nicht eintritt, würde mich übrigens
> interessieren. Eigentlich sollte das dort genauso laufen wie auf der
> lokalen Platte.
für die vhdx nicht per smb gemountet und greife nicht dateiweise zu,
sondern per iSCSI block basierend. Das könnte den Effekt "kaum
fragmentiert" erklären.
--
Thomas
Thomas Einzel
Jul 29, 2017, 10:13:04 AM7/29/17
to
Am 24.07.2017 um 17:52 schrieb Thomas Einzel:
...
Nach dem insider preview 16251 hatte die vhdx auch nach der
Datenträgerberinigung >30GB, also Zeit zum testen:
- (Datenträgerbeeinigung als Admin) (C: 14,5GB)
- Defragmentierung
- Komprimierung im Hyper-V-Manager (vhdx 18,5GB)
Also alles mit einfachen W10 Bordmitteln.
Die Ursache der kaum sichtbaren Wirksamkeit der Komprimierung im
Hyper-V-Manager bei lokalem Speicher für virtuelle Datenträger, würde
ich damit in erster Lesung in der Fragmentierung sehen. Auf automatisch
wöchentlich steht die Defragmentierung allerdings auch in der VM, ich
beobachte weiter.
...
vergleichsweise wenig, so dass ich es für den Vergleich nicht wirklich
testen kann und will.
--
Thomas
...
> Aber ja, nach den Hinweisen im Thread werde ich das nächste mal die
> Prozedur ohne sdelete testen.
Ingrids Anmerkungen:
> Prozedur ohne sdelete testen.
Nach dem insider preview 16251 hatte die vhdx auch nach der
Datenträgerberinigung >30GB, also Zeit zum testen:
- (Datenträgerbeeinigung als Admin) (C: 14,5GB)
- Defragmentierung
- Komprimierung im Hyper-V-Manager (vhdx 18,5GB)
Also alles mit einfachen W10 Bordmitteln.
Die Ursache der kaum sichtbaren Wirksamkeit der Komprimierung im
Hyper-V-Manager bei lokalem Speicher für virtuelle Datenträger, würde
ich damit in erster Lesung in der Fragmentierung sehen. Auf automatisch
wöchentlich steht die Defragmentierung allerdings auch in der VM, ich
beobachte weiter.
...
> Das stand im erwähnten link. Weiterhin habe ich den Platz auf dem NAS
> für die vhdx nicht per smb gemountet und greife nicht dateiweise zu,
> sondern per iSCSI block basierend. Das könnte den Effekt "kaum
> fragmentiert" erklären.
Bei den VMs die ihre vhdx im iSCSI Storage haben, passiert momentan nur
> für die vhdx nicht per smb gemountet und greife nicht dateiweise zu,
> sondern per iSCSI block basierend. Das könnte den Effekt "kaum
> fragmentiert" erklären.
vergleichsweise wenig, so dass ich es für den Vergleich nicht wirklich
testen kann und will.
--
Thomas
0 new messages