VM durch "Übersetzungsfehler" als Thick provisioned, lazily zeroed angelegt. Was nun?

[LoboNr1]

Hallo,
durch diesen besch... Übersetzungsfehler im WebIf von 6.7 habe ich versehentlich alle VMs als "Thick provisioned, lazily zeroed" angelgt. Wenn ich das jetzt richtig gelesen habe, ist das wohl die dümmste Version (wenig Performancen, viel Platzbedarf). Eigentlich wollte ich ja "Thin provisioned" damit das Datenvolumen bei Backups / dem kopieren der VM kleiner ist. Das schlimmste ist, das ich auch den neuen Windows Server 2019 so angelegt habe. Ich habe nun alle VMs die noch nicht fertig / wichtig waren gelöscht. Doch der Windows Server 2019 ist bereits als Domaincontroller für 4 Clients aktiv. Und einen Test PC hatte ich auch schon mit 500GB Platte

Nun habe ich versucht den Test PC via dieser Anleitung https://theitbros.com/convert-thick-pro ... ware-esxi/ zu konvertieren. Resultat: Ich habe ich nun auch gelöscht da die VM nach dem neu registrieren nicht mehr lief

Was mach ich nun mit dem Server??? Wie bekomme ich den auf "Thin provisioned"? Neu aufsetzen wollte ich den jetzt eigentlich nicht...

[JustMe]

Als "dümmste Version" wuerde ich das jetzt nun nicht unbedingt bezeichnen. Haengt halt vom Anwendungszweck ab (Stichwort Thin-provisioning Storage Device)...
Und "wenig Performance" stimmt auch nur beim allerersten Schreiben eines Blockes des Speichergeraets.
Abschliessend: Das zu sichernde Datenvolumen hat mit Thin/Thick pauschal erst einmal rein goarnuescht zu tun; es sei denn, man wuerde eine Ausfuehrung eines Copy-Befehls auf der ESXi-Commandline als "Sicherung" bezeichnen.

Der genannte Link beschreibt im Uebrigen recht gut unter "How to change disk provisioning type using ESXI CLI", was man tun sollte (ausreichend freier Speicherplatz vorausgesetzt). Wenn man dann noch weiss was man tut, kann eigentlich nix schiefgehen
Wichtig ist vielleicht erst einmal, dass man nicht auf die Idee kommt, die .vmx-Datei "mal eben" im Browser herunterzuladen, im Notepad.exe zu bearbeiten, und wieder hochzuladen.

PS, Obacht:
Gerade mal weitergelesen:
Also, erst das Original loeschen, um dann per mv die neue umzubenennen, wuerde ich jetzt dann doch nicht machen. Das ist toedlich.
Umbenennen von VMDK geht auch mit vmkfstools, und zwar mit Parameter -E. Zuerst wird die Original-Disk umbenannt, z.B. -old.vmdk, und danach die neue mit dem Namen der Original-Disk versehen. Dann spart man sich auch das Bearbeiten der .vmx (was, wenn alles richtig gegangen waere, auch im Browser per Einstellungen bearbeiten haette vornehmen koennen).

[LoboNr1]

Abschliessend: Das zu sichernde Datenvolumen hat mit Thin/Thick pauschal erst einmal rein goarnuescht zu tun; es sei denn, man wuerde eine Ausfuehrung eines Copy-Befehls auf der ESXi-Commandline als "Sicherung" bezeichnen.

Das Backup-Konzept ist leider noch unklar. Klar ist nur, dass es kein Budget gibt Ist ein kleines Familienunternehmen und der Chef gibt nichts für IT aus. Der arbeitet noch mit Zettel und Strift und meint das reicht...

Aber egal. Also gehe ich so vor?!?

Code: Alles auswählen

vmkfstools -i Windows Server 2019 Essentials.vmdk -d thin Windows Server 2019 Essentials-thin.vmdk


Dabei wir dann auch die Windows Server 2019 Essentials-flat.vmdk zu Windows Server 2019 Essentials-thin-flat.vmdk

Dann:

Code: Alles auswählen

vmkfstools -E Windows Server 2019 Essentials.vmdk Windows Server 2019 Essentials-OLD.vmdk

vmkfstools -E Windows Server 2019 Essentials-Thin.vmdk Windows Server 2019 Essentials.vmdk


Und was mache ich dann mit der -flat und wie geht es an der Stelle weiter?

[JustMe]

Die Befehle sind soweit erst einmal FAST korrekt.
Aber wer unbedingt Leerzeichen in Dateinamen verwenden moechte, muss die Dateinamen dann auch in Hochkommata ("Gaensefuesschen") packen:

Code: Alles auswählen

vmkfstools -i "Windows Server 2019 Essentials.vmdk" -d thin "Windows Server 2019 Essentials-thin.vmdk"

Und wenn Du hier im Namen "thin" schreibst, darfst Du dann spaeter nicht "Thin" nehmen (man beachte das "T").

Das meinte ich mit "wer weiss was er tut". Versteh' mich bitte nicht falsch; das soll nicht oberlehrerhaft klingen. Aber wer sich mit dem Aufbau von VMDKs schon eingehender beschaeftigt hat, oder einfach mal beim Beobachten des Forums ueber eine der zig Erwaehnungen "Der Datastore Browser zeigt NICHT die physisch vorhandenen Dateien!" gestolpert ist, hat bei genauer Betrachtung des Verzeichnisinhalts festgestellt, dass die <Name>.vmdk nur eine kleine (knapp 1KB) Textdatei ist, und die tatsaechlichen Daten in <Name>-flat.vmdk (bzw. auch -sparse, -delta, ...) liegen.
Das ist auch der Grund, warum der im von Dir zitierten Blog genannte Weg mit "mv" nur in's Chaos fuehren kann. Der vmkfstools-Befehl kennt dagegen die Begebenheiten, und geht mit den verknuepften Dateien korrekt um.
D.h.: Mit dem EINEN vmkfstools-Befehle werden tatsaechlich BEIDE zusammenhaengenden Dateien bearbeitet.

Zurueck vom Exkurs:
Danach kommen (fast) Deine naechsten beiden Befehle:

Code: Alles auswählen

vmkfstools -E "Windows Server 2019 Essentials.vmdk" "Windows Server 2019 Essentials-OLD.vmdk"

vmkfstools -E "Windows Server 2019 Essentials-thin.vmdk" "Windows Server 2019 Essentials.vmdk"

Damit brauchst Du dann nix mehr aendern; die VM sollte ohne Probleme hochlaufen, und die neuen Dateien verwenden.
Wenn Du mit allem zufrieden bist, ERST DANN loeschst Du die alten Dateien (entweder im DS Browser [dafuer ist er gerade noch gut]), oder, ganz penibel, auf der Kommandozeile

Code: Alles auswählen

mkdir tmp
mv Win*OLD*vmdk tmp
rm -rf tmp

(Bitte diese Befehle NUR so eintippen, und nur ohne Fehlermeldungen den jeweils naechsten Befehl verwenden. Sonst wieder hier melden [mit der Fehlermeldung].)

[~thc]

Übrigens: Wenn du dein erstes Kommando zur Datensicherung auf einen Backup-Datastore (z.B. auf einem NAS) benutzt, belegt das Backup auch nur den minimalen Platz.

[LoboNr1]

Super! Danke euch Werde ich so machen.

Und ein bischen weiß ich was ich tue . Doch leider nicht so gut wie ihr und der Aufbau der vmdk ist mir nicht bekannt. Und wenn mich das "oberlehrerhafte" stören würde, dann hatte ich den Sinn eines Forums nicht verstanden! Ich hoffe hier von Oberlehreren die mehr wissen Infos zu erhalten. Also alles gut. Danke.

[LoboNr1]

Hallo nochmal,
ich habe gestern das erste mal und heute das zweite Mal den ganzen Prozess durchgespielt und irgendwas stimmt da nicht. Die vmdk (-flat) wird nicht kleiner! Und auch im WebIf wird sie noch als Thick angezeigt. Hier der Prompt vom Zweiten Versuch:

[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] ls -lha
total 832738560
drwxr-xr-x 1 root root 76.0K Feb 4 10:43 .
drwxr-xr-t 1 root root 76.0K Feb 3 16:16 ..
-rw------- 1 root root 800.0G Feb 4 10:41 Windows Server 2019 Essentials-flat.vmdk
-rw------- 1 root root 8.5K Jan 30 21:22 Windows Server 2019 Essentials.nvram
-rw------- 1 root root 577 Feb 4 10:39 Windows Server 2019 Essentials.vmdk
-rw-r--r-- 1 root root 43 Feb 3 19:50 Windows Server 2019 Essentials.vmsd
-rwxr-xr-x 1 root root 3.6K Feb 4 10:41 Windows Server 2019 Essentials.vmx
-rw------- 1 root root 3.1K Jan 11 18:40 Windows Server 2019 Essentials.vmxf
-rw-r--r-- 1 root root 322.6K Feb 2 10:05 vmware-10.log
-rw-r--r-- 1 root root 317.5K Feb 3 10:55 vmware-11.log
-rw-r--r-- 1 root root 433.4K Jan 21 14:47 vmware-6.log
-rw-r--r-- 1 root root 338.0K Jan 27 10:41 vmware-7.log
-rw-r--r-- 1 root root 333.6K Jan 27 19:31 vmware-8.log
-rw-r--r-- 1 root root 443.8K Jan 30 21:22 vmware-9.log
-rw-r--r-- 1 root root 302.8K Feb 4 10:41 vmware.log
[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] vmkfstools -i "Windows Server 2019 Essentials.vmdk" -d thin "Windows Server 2019 Essentials-thin.vmdk"
Destination disk format: VMFS thin-provisioned
Cloning disk 'Windows Server 2019 Essentials.vmdk'...
[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] ls -lha
total 1665468672
drwxr-xr-x 1 root root 76.0K Feb 4 12:56 .
drwxr-xr-t 1 root root 76.0K Feb 3 16:16 ..
-rw------- 1 root root 800.0G Feb 4 10:41 Windows Server 2019 Essentials-flat.vmdk
-rw------- 1 root root 800.0G Feb 4 10:43 Windows Server 2019 Essentials-thin-flat.vmdk
-rw------- 1 root root 582 Feb 4 12:56 Windows Server 2019 Essentials-thin.vmdk
-rw------- 1 root root 8.5K Jan 30 21:22 Windows Server 2019 Essentials.nvram
-rw------- 1 root root 577 Feb 4 10:39 Windows Server 2019 Essentials.vmdk
-rw-r--r-- 1 root root 43 Feb 3 19:50 Windows Server 2019 Essentials.vmsd
-rwxr-xr-x 1 root root 3.6K Feb 4 10:41 Windows Server 2019 Essentials.vmx
-rw------- 1 root root 3.1K Jan 11 18:40 Windows Server 2019 Essentials.vmxf
-rw-r--r-- 1 root root 322.6K Feb 2 10:05 vmware-10.log
-rw-r--r-- 1 root root 317.5K Feb 3 10:55 vmware-11.log
-rw-r--r-- 1 root root 433.4K Jan 21 14:47 vmware-6.log
-rw-r--r-- 1 root root 338.0K Jan 27 10:41 vmware-7.log
-rw-r--r-- 1 root root 333.6K Jan 27 19:31 vmware-8.log
-rw-r--r-- 1 root root 443.8K Jan 30 21:22 vmware-9.log
-rw-r--r-- 1 root root 302.8K Feb 4 10:41 vmware.log
[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials]

[~thc]

Das

Code: Alles auswählen

ls -lah

Kommando zeigt nicht den belegten Platz an. Im (zur Abwechslung mal nützlichen) Datastore-Dateisystembrowser des Web- oder HostClients sollte man die aktuelle Größe sehen.

[JustMe]

Ich persoenlich bleibe da immer noch lieber vom DS Browser weg, und verwende

Code: Alles auswählen

du *
du -sh *

[JustMe]

PS, bis die Disk Usage Werte kommen:
Ist die Srv2019-Platte eventuell Bitlocker-verschluesselt?

[LoboNr1]

[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] ls -lah
total 1665468672
drwxr-xr-x 1 root root 76.0K Feb 4 12:56 .
drwxr-xr-t 1 root root 76.0K Feb 3 16:16 ..
-rw------- 1 root root 800.0G Feb 4 10:41 Windows Server 2019 Essentials-flat.vmdk
-rw------- 1 root root 800.0G Feb 4 10:43 Windows Server 2019 Essentials-thin-flat.vmdk
-rw------- 1 root root 582 Feb 4 12:56 Windows Server 2019 Essentials-thin.vmdk
-rw------- 1 root root 8.5K Jan 30 21:22 Windows Server 2019 Essentials.nvram
-rw------- 1 root root 577 Feb 4 10:39 Windows Server 2019 Essentials.vmdk
-rw-r--r-- 1 root root 43 Feb 3 19:50 Windows Server 2019 Essentials.vmsd
-rwxr-xr-x 1 root root 3.6K Feb 4 10:41 Windows Server 2019 Essentials.vmx
-rw------- 1 root root 3.1K Jan 11 18:40 Windows Server 2019 Essentials.vmxf
-rw-r--r-- 1 root root 322.6K Feb 2 10:05 vmware-10.log
-rw-r--r-- 1 root root 317.5K Feb 3 10:55 vmware-11.log
-rw-r--r-- 1 root root 433.4K Jan 21 14:47 vmware-6.log
-rw-r--r-- 1 root root 338.0K Jan 27 10:41 vmware-7.log
-rw-r--r-- 1 root root 333.6K Jan 27 19:31 vmware-8.log
-rw-r--r-- 1 root root 443.8K Jan 30 21:22 vmware-9.log
-rw-r--r-- 1 root root 302.8K Feb 4 10:41 vmware.log

Die Serverplatten sind sicher nicht verschlüssel. Das kann es nicht sein.

Thin.JPG (12.99 KiB) 4133 mal betrachtet

[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] du -sh *
794.2G Windows Server 2019 Essentials-flat.vmdk
794.2G Windows Server 2019 Essentials-thin-flat.vmdk
0 Windows Server 2019 Essentials-thin.vmdk
64.0K Windows Server 2019 Essentials.nvram
0 Windows Server 2019 Essentials.vmdk
0 Windows Server 2019 Essentials.vmsd
64.0K Windows Server 2019 Essentials.vmx
0 Windows Server 2019 Essentials.vmxf
1.0M vmware-10.log
1.0M vmware-11.log
1.0M vmware-6.log
1.0M vmware-7.log
1.0M vmware-8.log
1.0M vmware-9.log
1.0M vmware.log

[JustMe]

Mysterioes...
Wie ist denn die Platte partitioniert, und die Partitions im Gast belegt?
Hast Du schon Antwort 7 probiert?

[LoboNr1]

Mysterioes...
Wie ist denn die Platte partitioniert, und die Partitions im Gast belegt?
Hast Du schon Antwort 7 probiert?

Meinst du

vmkfstools -K [disk].vmdk

oder den Rest auch?

[JustMe]

Wichtig ist der sdelete, damit wirklich Nullen in die nicht genutzten Bloecke kommen, und dann vmkfstools -K fuer PunchZero (oder so).
"Der Rest", also die Geschichte mit Thin-provisioning Storage Devices und unmap usw. ist bei lokalem Speicher in aller Regel nicht noetig.

[LoboNr1]

OK, probiere ich. Dazu muss ich aber erst die "alte vmdk" in -old umbennenne und dann die -thin zur "neuen vmdk" umbenennen:

[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] du -sh *
794.2G Windows Server 2019 Essentials-flat.vmdk
794.2G Windows Server 2019 Essentials-thin-flat.vmdk
0 Windows Server 2019 Essentials-thin.vmdk
64.0K Windows Server 2019 Essentials.nvram
0 Windows Server 2019 Essentials.vmdk
0 Windows Server 2019 Essentials.vmsd
64.0K Windows Server 2019 Essentials.vmx
0 Windows Server 2019 Essentials.vmxf
1.0M vmware-10.log
1.0M vmware-11.log
1.0M vmware-6.log
1.0M vmware-7.log
1.0M vmware-8.log
1.0M vmware-9.log
1.0M vmware.log
[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] vmkfstools -E "Windows Server 2019 Essentials.vmdk" "Windows Server 2019 Essentials-OLD.vmdk"
[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] vmkfstools -E "Windows Server 2019 Essentials-thin.vmdk" "Windows Server 2019 Essentials.vmdk"
[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] du -sh *
794.2G Windows Server 2019 Essentials-OLD-flat.vmdk
0 Windows Server 2019 Essentials-OLD.vmdk
794.2G Windows Server 2019 Essentials-flat.vmdk
64.0K Windows Server 2019 Essentials.nvram
0 Windows Server 2019 Essentials.vmdk
0 Windows Server 2019 Essentials.vmsd
64.0K Windows Server 2019 Essentials.vmx
0 Windows Server 2019 Essentials.vmxf
1.0M vmware-10.log
1.0M vmware-11.log
1.0M vmware-6.log
1.0M vmware-7.log
1.0M vmware-8.log
1.0M vmware-9.log
1.0M vmware.log
[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials]

Komisch ist nur das im WebIf die Platte nicht als Thin erkannt wird:

[LoboNr1]

Läuft:

E:\Software_Server>sdelete64.exe -z C:

SDelete v2.02 - Secure file delete
Copyright (C) 1999-2018 Mark Russinovich
Sysinternals - www.sysinternals.com

SDelete is set for 1 pass.
Free space cleaned on C:\
1 drive cleaned.

E:\Software_Server>sdelete64.exe -z E:

SDelete v2.02 - Secure file delete
Copyright (C) 1999-2018 Mark Russinovich
Sysinternals - www.sysinternals.com

SDelete is set for 1 pass.
Free space cleaned on E:\
1 drive cleaned.

E:\Software_Server>sdelete64.exe -z D:

SDelete v2.02 - Secure file delete
Copyright (C) 1999-2018 Mark Russinovich
Sysinternals - www.sysinternals.com

SDelete is set for 1 pass.
Free space cleaned on D:\
1 drive cleaned.

E:\Software_Server>

[Dayworker]

Was ich nicht verstehe ist, weshalb du nur 1 vDISK mit 800GB angelegt hast und darin vorsinnflutlich mit mehreren Partitionen rummachst. Wenn du mal eine der vorderen Partitionen vergrössern willst, weißt du weshalb ich da von vorsinnflutlich spreche. Braucht man 3 Laufwerke, richtet man einfach 3 vDISKs ein. Diese lassen sich später nämlich nach belieben und völlig unabhängig von den anderen Laufwerken vergrössern.
Muß in deiner jetzigen Konfiguration Laufwerk C vergrössert werden, kannst du nicht einfach die vDISK vergrössern und dann nur die Partitionsgrösse im Gast online an/auf die neue vDISK-Grösse anpassen/erweitern, weil die dahinter liegenden Partitionen im Weg sind. Bei dir besteht der Weg darin, wie normal die vDISK zu vergrössern, dann erstmal die Partitionen von hinten gezählt sprich zuerst E dann D jeweils ans neue Ende der vDISK zu verschieben und im Anschluß die C-Partition zu vergrössern. Da sich solche Partitionierungsaufgaben im Gegensatz zu einer simplen Erweiterung nicht online machen lassen, mußt du mit einer völlig unnötigen, langen VM-Downtime leben, bei der das Verschieben von Partitionen auch mal schiefgehen kann, was das Einspielen eines Backups erforderlich macht.

Ich würde auch behaupten, daß du eine VMDK mit mehreren Partitionen durch die dann mehrfach enthaltenen MBR- bzw GPT-Informationen auch längst nicht so geschrumpft bekommst, wie es mit Einzel-Laufwerken der Fall wäre.

[LoboNr1]

Sieht aus als hat es geklappt.

[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] vmkfstools -K "Windows Server 2019 Essentials.vmdk"
vmfsDisk: 1, rdmDisk: 0, blockSize: 1048576
[root@localhost:/vmfs/volumes/5c34a17d-1a402214-6934-901b0e046467/Windows Server 2019 Essentials] du -sh *
794.2G Windows Server 2019 Essentials-OLD-flat.vmdk
0 Windows Server 2019 Essentials-OLD.vmdk
16.3G Windows Server 2019 Essentials-flat.vmdk
64.0K Windows Server 2019 Essentials.nvram
0 Windows Server 2019 Essentials.vmdk
0 Windows Server 2019 Essentials.vmsd
64.0K Windows Server 2019 Essentials.vmx
0 Windows Server 2019 Essentials.vmxf
1.0M vmware-10.log
1.0M vmware-11.log
1.0M vmware-12.log
1.0M vmware-7.log
1.0M vmware-8.log
1.0M vmware-9.log
1.0M vmware.log

Wird aber noch immer als Thick angezeigt

[LoboNr1]

Reboot tut gut! Euch allen vielen DANK!!!

[Dayworker]

Bleibt nur noch, daß bei einer Laufwerkvergrösserung völlig unnötige Zwischenschritte eingeschoben werden müssen. Falls der Server nicht bereits produktiv läuft, würde ich das noch korrigieren. Du wärest nicht der erste Benutzer, der sich beim Platzbedarf von M$-Updates und Anwendungen verschätzt hat. Unnötig groß würde ich Laufwerke auch nicht anlegen, da diese sich nicht so einfach wieder verkleinern lassen.

[LoboNr1]

Bleibt nur noch, daß bei einer Laufwerkvergrösserung völlig unnötige Zwischenschritte eingeschoben werden müssen. Falls der Server nicht bereits produktiv läuft, würde ich das noch korrigieren. Du wärest nicht der erste Benutzer, der sich beim Platzbedarf von M$-Updates und Anwendungen verschätzt hat. Unnötig groß würde ich Laufwerke auch nicht anlegen, da diese sich nicht so einfach wieder verkleinern lassen.

ÖÖÖÖÖÖÖÖÖÖhhhhhhhhhhhhhhhh, was? Du meinst die Laufwerke meines Server sind zu klein? Vorschläge?

[Dayworker]

Nö, jetzt vielleicht noch nicht und es gibt dafür auch keine allgemein bzw dauerhaft gültige Grösse. Man legt statt 1 vDISK entsprechend den Bedürfnissen entsprechend mehr vDISKs an und umgeht damit das Rumgeeier mit mehreren Partitionen in einer vDISK. Die vDISK mit 800GB hast du ja in 3 Partitionen unterteilt.

Falls man mal Platzmangel auf einen Datastore hat, kann man die vDISKs auch einfacher auf mehrere Datastores aufteilen. Das ist zwar etwas unschön, wenn man nicht mehr daran denkt und dann ggf nur einen Teil kopiert. Man kann damit aber bei Platzmangel bzw vollgelaufenen DS zumindest eine kurzfristige Linderung schaffen. Wer mit Thin-provisioned vDISKs hantiert, sollte sowieso eine Platzüberwachung vornehmen, damit der DS eben nicht unkontrolliert vollläuft und somit Datenverlust unvermeidbar ist. Es reicht bereits aus, mal schnell ein Format-C-Doppelpunkt anzuschieben und dabei nicht Schnellformat auszuwählen. Dann wächst eine Thin-vDISK mal Ruckzuck auf die maximale, als vDISK spezifierte Grösse an und damit laufen auch TB-große DS schnell mal voll.

[LoboNr1]

OK, verstanden. Nur um den physikalischen Speicher des Servers muss ich mir kaum sorgen machen, da dieser über 2,73TB (8x500GB im RAID6) verfügt. Das reicht mir locker denn außer dem Windows Server 2019 Essential laufen nur zwei Windows 10 Maschienen dauerhaft auf dem Server. Die restlichen VMs sind spielerei...
Und auch bei D: für die WaWi und E: für die Daten der 4 Clients sehe ich aus der Erfahrung mit dem aktuellen Windows Server 2008 R2 Foundation kein Problem.
Nur bei C: bin ich mir nicht sicher ob die 199GB dauerhaft reichen. Der Server soll zwar außer der WaWi nur DomainController, DHCP und FileServer (mit E:) sein, aber mir fehlt die Erfahrung mit Server 2019

P.S.: Der Server ist noch nicht produktiv, aber die 4 "neuen" Clients sind schon in der AD angemeldet und diese ist teilweise konfiguriert.

[~thc]

Ich habe nur einen produktiven 2016-Server und der belegt im Moment ca. 70 GB auf C:. In den nächsten Jahren werden noch einige GB hinzukommen (Windows Update, WinSxS), aber seit diesem Release darf man auch auf dem Server aufräumen (Datenträgerbereinigung).

[LoboNr1]

So, hab noch mal drüber nachgedacht und ich werde die 3 Partitionen auf 3 VMDKs aufteilen. Wie mache ich das am dummsten? Und die aktuelle 800GB würde ich gerne vorerst auf 200GB verkleinern.