Hallo zusammen,
ich bin mir gerade nicht sicher, wie ich wo vorgehen muss, wenn ich die Größe meines Images ändern will.
Konkret: Ich habe eine 30GB Partition für Linux Mint und entsprechend ein 30GB-Image.
Jetzt sehe ich, dass mir 15GB reichen und ich würde das entsprechend reduzieren wollen.
Muss ich jetzt sowohl die Partition (via WebUI) als auch das Image (wie?) verkleinern?
Vielen Dank schon mal für Tip(p)s,
Guntram
Hallo Guntram,
… ich bin mir nicht sicher, dass du das meinst, was ich hier in deiner Nachricht verstehe.
Ich antworte mal auf das, wie ich es verstehe.
Du kannst das Image verkleinern, indem du Dinge auf dem Client löschst, und danach ein neues Image erstellst (Papierkorb leeren nicht vergessen).
Den Satz: " Ich habe eine 30GB Partition für Linux Mint und entsprechend ein 30GB-Image."
Verstehe ich nicht. Die Partition ist also 30 GB groß. Aber dann ist doch das Image niemals 30 GB groß. Wie kommst du den auf die Idee, das sei 30GB groß
Bitte poste doch mal die Angaben aus der start.conf.GRUPPE und die größe der Imagedatei und sag uns dann nochmal, was du willst.
LG
Holger
Hallo Holger,
stimmt - ich frage mal anders:
Ist die Partitionsgröße erst einmal unabhängig von der Image-Größe? Sprich: der Rest der Partition füllt sich entsprechend auf?
Was will ich eigentlich erreichen: beim Image-Erstellen wird so lange gebraucht, die aktuelle Partition komplett zu erfassen und erst anschließend zu reduzieren. Wenn ich also die Partition kleiner mache, sollte das Erstellen von Images schneller gehen - richtig?
Im Prinzip hast Du meine Frage oben wohl schon beantwortet ;-).
Danke,
Guntram
Hallo Guntram,
Ich führe mal folgende Begriffe ein: Imagegröße = Größe der qcow2 Datei
Partitionsgröße = Größe der Partition.
Die Imagegröße hängt von der Menge an Dateien (Gigabyte) in der Vorlagenpartition ab. Der Inhalt wird komprimiert bei der Imageerstellung auf 1/3 bis 1/2 der Größe.
Nehmen wir mal 1/2 an.
Wenn du in der Vorlagenpartition, die 60GB groß ist, 20 GB Daten hast, dann ist das Image am Ende ca. 10 GB groß.
Nun ist die Frage: hast du Windows (NTFS) oder Linux (ext4).
Bei Windows wird vor dem Erstellen des Images der freie Bereich der Vorlagenpartition genullt: und das ist das, was dich stört, weil das lange dauert.
Bei ext4 wird das nicht gemacht.
Jetzt würde ich aber nicht di ePartition verkleineren, nur weil das Erstellen der Images halt etwas länger dauert: macht man ja nicht oft …
Ich bespiele gerade dei Yogas für die Lehrer (Lehrerleihgeräte): die haben eine 500GB SSD und die Windowspartition ist 440GB groß … ja, da dauert das Erstellen lange, weil ca. 410GB genullt werden müssen.
Beim Rückspielen ist das wurscht: da dauert es nicht länger, auch wenn es eine riesenpartition ist: da kommt es nur auf die Imagegröße an.
Ich hoffe, dass jetzt alle Klarheiten beseitigt sind 
LG
Holger
ich glaube, das ist das nullen des „rests“ der Partition. Ich vage mal noch zu behaupten: das Nullen passiert auch unter Linux, denn das dauert bei mir auch immer erstaunlich lange (trotz M2-SSDs). Ich beobachte das das nächste Mal live mit…
VG, Tobias
Danke - sehr gute Erklärung. Ich kann also die Images auf beliebige Partitionen spielen, solange die Partition groß genug ist ;-).
Wenn ich hier noch kurz zwei Fragen zu den differentiellen Images anhängen darf:
1.) Mir scheint so, als würden die Kommentare, welche bei der Erzeugung angegeben werden, nicht mehr in der Imageverwaltung in der WebGUI auftauchen - ist das beabsichtigt?
2.) Wie „sicher“ sind die Diffs? Ist der Fall berücksichtigt, dass ich an zwei Rechner gleichzeitig arbeite und Images hochlade?
Szenario:
Rechner A macht Image 09:00
Rechner B macht diffImage 10:00
Rechner C mach diffImage 11:00 ausgehend vom 09:00-Image
Fällt dann die Änderung von B einfach hinten runter oder die Änderung von C (weil sich ja nicht aus das aktuelleste (Image+Diff) Image bezogen wurde)?
Vielen Dank und LG,
Guntram
Hallo Guntram,
das diffimage legt eine Imagedatei mit allen Differenzen zum Basisimage an. Natürlich geht das „B“ Image in deinem Beispiel, wenn der Client von dem das „C“ Image erstellt wird nicht vorher mit „B“ geimaged wurde, verloren.
Woher soll den der C Client ohne sync des B Images wissen, was da passiert ist?
LG
Holger
Es hätte ja sein können, dass B-diff und C-diff dann noch einmal miteinander (auf dem Server) „verrechnet“ werden, um ein neues Diff zu erzeugen ;-).
Ist das System dann inkrementell → sprich aufeinanderfolgende Diffs beziehen sich auf Image+vorherigeDIffs oder wird das jeweilige (neuere) Diff immer relativ zum ursprünglichen Image gemacht?
Danke,
Guntram