VMware-Forum

Hallo Leute,

soweit ich herausgefunden habe, funktioniert ein einfaches verkleinern einer bereits angelegten VM nicht ohne sich händisch einzumischen.

Zwei Möglichkeiten:


"sichere die Partitionen der Festplatte und hänge die Festplatte dann ab. Erstelle eine neue kleinere Festplatte und mache darauf die Rücksicherung."

"oder bau eine 2te - kleinere Platte in die VM ein - boote dann von einer LiveCD mit Ghost und clone disk2disk"

Wobei ich die zweite Lösung verwenden würde. Leider funktioniert das mit Norton Ghost und der BootCD nicht, da ich keine Disk2Disk Kopie durchführen kann (kein passender Menüpunkt). CloneZilla macht es auch nicht mit, da die Zielpartition kleiner als die originale ist.
Welche Programme bleiben dann noch übrig?

Zweites Problem was ich habe, sind die VM's welche verkleinert werden sollen. Zum einen wäre das unser Domänencontroller (Master) zum zweiten eine VM auf dem unsere Autodesk Vault SQL Datenbank liegt.

Werden die Daten tatsächlich 1:1 kopiert ohne irgendwelche Änderungen so dass der Domänencontroller und die SQL Datenbank nicht beschädigt werden?!

Vielleicht kannst du CloneZilla doch einsetzen - wenn du die Quellpartitionen vorher schon auf die Zielgröße verkleinerst. Windows Server 2008 R2 z.B. kann in der Datenträgerverwaltung auch Volumes verkleinern - ob das mit deinen VMs auch geht, kann ich nicht vorhersagen. Auf jeden Fall sollte vorher ein komplettes Backup angelegt werden.

Wenn das Volume 1:1 kopiert wird, gehen keine Informationen verloren.

Ich würde wahrscheinlich eher (wenn man sowas überhaupt tun sollte) die Maschine erneut virtualisieren. Heißt der VM glaubhaft machen sie wäre eine physische Maschine und sie dann wie alle anderen physischen Server auch virtualisieren.

m.mart1n hat geschrieben:Heißt der VM glaubhaft machen sie wäre eine physische Maschine

Ja, ja, erst VMs anlügen und dann von ihnen verlangen, dass sie einem vertrauen und tun was sie sollen.
Arme VMs, wenn man das mit Dir machen würde!
Sollte aber gehen.

1. AD Rollen umziegen, DC herunterstufen und entfernen. Neues System installieren und zum DC hochstufen
2. Entweder SQL Instanz umziehen was Problemlosgehen sollte wenn es eine Express ist. Ansonsten SQL Dienst stoppen und per VMware Konverter einen Hotclone mache und dabei die Volumes verkleinern

Der Schritt 2. darf nicht gemacht werden solange der DC dort aktiv ist.

Gruss
Joerg

Vollautomtisch hab ich auch nix. Einmal mit gparted booten und verkleinern und fertig. Unter Windows huscht chkdsk noch drüber und dann ist die Sache normalerweise gegessen.

UrsDerBär hat geschrieben:Vollautomtisch hab ich auch nix. Einmal mit gparted booten und verkleinern und fertig. Unter Windows huscht chkdsk noch drüber und dann ist die Sache normalerweise gegessen.

Wäre ich bei einem DC sehr vorsichtig. Restore von einem DC ist immer so eine Sache und wenn er nicht mehr läuft ihn dann aus dem System mit ntdsutil zu entfernen ist auch nicht grad eine Anfängerübung von Microsoft.

Na beim DC kannst ja einfach nen zusätzlichen promoten und den ersten anschliessend rauskippen. Ansonsten kannst immer noch erst nen Backup via WindowsBackup (Systemstate) ziehen, verkleineren und anschliessend den SystemState via WindowsBackup zurückspielen.

Oder DC demoten, verkleineren, und wieder promoten. (Sofern mehrere, wovon ich mal ausgehe)

Ich wollte damit auch nur ausdrücken das ich bei einem DC auf jeden Fall eine Sicherung machen würde bevor ich mit irgendwelchen Partitionierungstools etwas ändere

DC sichern bringt doch sowieso nix, da beim es beim Zurückspielen nur zu Problemen kommt. Ich seh schon, sowas wie eine einfache Lösung gibts da nicht.

Sinnlos is halt, dass ich nicht wussten, dass man die Partitionen auf einfachem Weg nicht verkleinern kann, dafür aber umso einfacher vergrößern. Dann hätte ich gleich weniger Speicher für die Partitionen der zwei VM's vergeben. So verschwende ich gerade gesamt über 100GB kostenbaren speicher.

Ist es möglich die vmdk's von Thick auf Thin umzustellen. Ist es egtl nicht immer besser Thin zu wählen?

Beim klonen einer Maschine kann man von thick auf thin umstellen. Aber normal macht man nur thick, ich zumindest.
Es ist fatal wenn man den Überblick verliert und ein Datastore auf einmal voll ist. Passieren kann sowas relativ schnell. Bei mir meinte auch schon mal ein User seine 300 GB D: Partition vom Notebook auf dem Fileserver sichern zu müssen und schon konnte keiner mehr was machen. Stell dir mal vor sowas passiert mit einer thin Platte und der Datastore wo 10 VMs drauf zugreifen ist voll.

lalanunu hat geschrieben:DC sichern bringt doch sowieso nix, da beim es beim Zurückspielen nur zu Problemen kommt. Ich seh schon, sowas wie eine einfache Lösung gibts da nicht.

Warum sollte ein zurücksichern Probleme geben? Man muss nur Windows-Backup SystemState nehmen (auch die einzige von MS supportete Methode!)

Wie gesagt, bei nem DC eh völlig schmerzfrei. Neuen Hinzu, warten bis syncro, alten entfernen. Fertig. Hat der alten FSMO-Rollen, diese vorzugsweise vorgängig übertragen.

m.mart1n hat geschrieben:Beim klonen einer Maschine kann man von thick auf thin umstellen. Aber normal macht man nur thick, ich zumindest.
Es ist fatal wenn man den Überblick verliert und ein Datastore auf einmal voll ist. Passieren kann sowas relativ schnell. Bei mir meinte auch schon mal ein User seine 300 GB D: Partition vom Notebook auf dem Fileserver sichern zu müssen und schon konnte keiner mehr was machen. Stell dir mal vor sowas passiert mit einer thin Platte und der Datastore wo 10 VMs drauf zugreifen ist voll.

Es würden nur vmdk's umgestellt, auf die Normaluser keinen Zugriff haben.

Na ja.. ich mach mir hier mal weiter nen Kopf wie ich das am Besten löse...

P.S. Bei uns wurde die vCenter virtual Appliance eingerichtet (ja ich weiß, dass is Mist). Für diese wurden ca. 93GB vergeben. Aus meiner Sicht viel zu viel für 2 ESXI und zur Zeit noch 6 VM's (auf längere Sicht nicht mehr als 20 VM's). Jetzt ist meine Frage, ob ich diese nachträglich noch verkleinern kann. Wenn das nicht geht, ist es möglich diese von einen auf den anderen Dateispeicher zu verschieben?! Wenn dann nur mit vMotion, weil das im laufenden Betrieb passieren muss?

Mal so nebenbei. In der virtualisierten Welt galt schon immer: "Nur soviel wie nötig (vRAM, vCPU, vDISK) und nicht wie möglich!"

Ob die 93GB zuviel sind, kann man ohne Wissen um die Log-Einstellungen und vor allem den Zeitraum so nicht sagen. Genauso siehts mit der vCenter Appliance aus. Wenn man kein 64bit-Server-OS dafür extra aufsetzen will, tut es auch die Appliance mit ihren Einschränkungen hinsichtlich VM- und ESXi-Verwaltungsanzahl.

Ich kann mich nun garnicht dran erinneren das man auf die Groesse der vDISKS der VCSA Appliance so direkten Einfluss hat. Wenn ueberhaupt machst du bei Deployment Thinprovisioning und das war es dann.

Jetzt hinterher ist es unschoen weil es geht nur noch
1. Du hast svMotion
2. Shutdown der VM und konvertierung auf CMD
3. Noch einmal neu deployen

weil fuer ein normale Migration muss die VM ausgeschaltet seinm, aber das Feature funktioniert nur mit einem lfd. vCenter und somit kann es sich selber nicht konvertieren.

Gruss
Joerg

Bin hier gerade etwas am rumprobieren.

Wenn ich eine VM Migriere (Datenspeicher ändern) dann kann ich doch auch das Format der virtuellen Festplatte auf Thin Provision ohne weiteres umstellen?!

Kann es dabei zu Problemen kommen?

Ja das kannst du.

Nein das ergibt keine Probleme.

Aber, obs was bringt haengt damit zusammen ob im Filesysteme eine NULL steht damit alle beteiligten Wissen das dort auch keine Daten mehr sind. Wenn dein Windows OS mal was loescht dann tut es das nicht wirklich sondern entfernt nur einen Verwaltungseintrag um bei Bedarf den Platz zu ueberschreiben. Ein vSphere Thinprovisioning profitiert davon nicht. Da brauchts etwas Vorbereitung (sdelete.exe)

Bei Thinprovisioning dann bitte auch ein akt. Monitoring der freien Resourcen einrichten weil sonst ist das geschrei irgendwann sehr gross.

Gruss
Joerg

Das Löschen nicht gleich Löschen ist, habe ich auch schon rausfunden... wenigstens schon etwas gelernt

Ohne den Datenstore zu ändern kann man mit der Migrierenfunktion nicht auf Thin umstellen?

Was verstehst du unter aktives Monitoring?! Wie und wo richte ich das ein? Reicht es wenn ich hier irgendwann mal das Veeam ONE zum laufen bekomme oder welche Möglichkeiten habe ich da?

lalanunu hat geschrieben:Das Löschen nicht gleich Löschen ist, habe ich auch schon rausfunden... wenigstens schon etwas gelernt

Google mal nach sdelete im zusammen hang mit VMware Virtuellen Maschinen

Ohne den Datenstore zu ändern kann man mit der Migrierenfunktion nicht auf Thin umstellen?

Du stellst nicht den Datastore um sondern das Format des Diskcontainers. Sprich ueber die GUI wird ein

gemacht wobei er es hinterher wieder passend umbenennt wenn man die GUI verwendet.

Wie gross die Einsparung ist haengt davon hab wieviel das OS schon im Filesystem verbraucht hat. Wobei man ja mit sdelete aufrauemen kann.

Was verstehst du unter aktives Monitoring?! Wie und wo richte ich das ein? Reicht es wenn ich hier irgendwann mal das Veeam ONE zum laufen bekomme oder welche Möglichkeiten habe ich da?

Wenn du dumme aktionen im Gast OS machst welche nun den Speicherplatz in Anspruchnehmen welche das OS ja glaubt zuhaben, dein Datastore aber unten drunter garnicht mehr an freien Speicher hat dann kann dieser ja mal 100% erreichen. Passiert dies bleiben alle VMs welche Thinprov. verwenden oder aber Snapshots haben stehen.

Da man zum loeschen oftmals aber Platz braucht ist dies eine unschoene Situation. Das heist der freie Platz muss ueberwacht und die Leute muessen wissen was man in der VM zu unterbleiben hat.

Gruss
Joerg

irix hat geschrieben:Du stellst nicht den Datastore um sondern das Format des Diskcontainers. Sprich ueber die GUI wird ein

Code: Alles auswählen

vmkfstools -i  lazyzerothick.vmdk  thin.vmdk -d thin

gemacht wobei er es hinterher wieder passend umbenennt wenn man die GUI verwendet.

Ja aber wie genau gehe ich vor? Wenn ich meine TestVM auswähle und auf "Migrieren..." gehe, dann auf "Datenspeicher ändern" und hier den selben Datenspeicher auswähle und das Format für die virtuelle Festplatte ändere, dann ändert sich das Format aber nicht. Muss ich zwangsläufig auch den Datenspeicher ändern, sodass wirklich kopiert wird?

Umstellen kannst du das VMDK-Format nur beim Anlegen einer VM oder nachher per SSH auf der busybox per vmkfstools und die Syntax hat dir irix auch bereits gelistet.