Problem bei der Zusammenführung von vmdk Containern

[Mr. T]

@JustMe

Code: Alles auswählen

System information as of Wed Jul 31 19:54:01 CEST 2013
System load:  0.0                Processes:             114
Usage of /:   17.2% of 18.45GB   Users logged in:       1
Memory usage: 45%                IP address for eth0:   XXX.XXX.XXX.XXX
Swap usage:   4%                 IP address for virbr0: XXX.XXX.XXX.XXX
 
user@ubuntu:~$ sudo df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu-root   19G  3.2G   15G  19% /
udev                     494M  4.0K  494M   1% /dev
tmpfs                    201M  936K  200M   1% /run
none                     5.0M     0  5.0M   0% /run/lock
none                     502M     0  502M   0% /run/shm
cgroup                   502M     0  502M   0% /sys/fs/cgroup
/dev/sda1                228M   26M  190M  12% /boot
user@ubuntu:~$

user@ubuntu:~$ sudo fdisk -l
Disk /dev/sda: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009daf9

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      499711      248832   83  Linux
/dev/sda2          501758    41943039    20720641    5  Extended
/dev/sda5          501760    41943039    20720640   8e  Linux LVM

Disk /dev/mapper/ubuntu-root: 20.1 GB, 20124270592 bytes
255 heads, 63 sectors/track, 2446 cylinders, total 39305216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/ubuntu-root doesn't contain a valid partition table

Disk /dev/mapper/ubuntu-swap_1: 1069 MB, 1069547520 bytes
255 heads, 63 sectors/track, 130 cylinders, total 2088960 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/ubuntu-swap_1 doesn't contain a valid partition table
user@ubuntu:~$

Vom freien Platz her schaut es nun wieder sehr gut aus. Was mich allerdings wundert:
Warum steht bei /dev/mapper/ubuntu-root und /dev/mapper/ubuntu-swap_1

doesn't contain a valid partition table

Ist das bedenklich oder ok?

@Dayworker
Danke für die guten Infos. Ich schaue mir den verlinkten Beitrag mal an und mache mir Gedanken dazu.

[JustMe]

Das sieht in der Tat gut aus; eine Verkleinerung um bis zu 15G sollte möglich sein.

Wenn Du jetzt noch wie erwaehnt einmal die 15G mit Nullen vollschreibst, die Nuller-Datei wieder loeschst, und die vmdk erneut durch den vmware-diskmanager jagst, sollte die Ziel-vmdk erheblich kleiner werden, und Du haettest weiterhin in der Zukunft die Moeglichkeit, bis zu 20GB in die vmdk zu schreiben.

Die Meldungen zu "doesn't contain a valid partition table" sollten der Verwaltung ueber den LVM geschuldet sein, und vmtl. auch die Probleme mit gparted verursachen.

Falls der LVM-Wrapper aber auch noch Verschluesselung betreiben sollte, dann wuerden die geschriebenen Nullen natuerlich auch verschluesselt, und somit wuerde der vmware-diskmanager nichts mehr zum Optimieren finden. Spaetestens dann bin ich fertig mit meinen Vorschlaegen; da habe ich keine Erfahrung und keine Tipps mehr, sorry.

[Mr. T]

Wenn Du jetzt noch wie erwaehnt einmal die 15G mit Nullen vollschreibst, die Nuller-Datei wieder loeschst, und die vmdk erneut durch den vmware-diskmanager jagst, sollte die Ziel-vmdk erheblich kleiner werden, und Du haettest weiterhin in der Zukunft die Moeglichkeit, bis zu 20GB in die vmdk zu schreiben.

Könntest du das bitte nochmal auf Laien-Deutsch sagen? Wie macht man so etwas?

[JustMe]

Schau' doch mal in Dayworker's letztes Posting. Da stehen am Ende die Schritte drin.

[Mr. T]

Oh ja, richtig. Das hatte ich übersehen.
Allerdings, so wie ich das verstehe, ist sda1 meine unter /boot gemountete boot-Partition. Wenn ich die nach Dayworkers Algo unter /media mounte und von vorn bis hinten mit 0en überschreibe, lösche ich diese Partition doch vollständig. Im Schluss hieße das, ich mache das ganze System platt und verliere meine ganzen Daten ... und ... kann nicht mehr booten!?

[Dayworker]

Nö, Schritt 3 ist "sudo dd if=/dev/zero of=0bits bs=20971520" und beschreibt die freien Bereiche der unter "/media" eingehängte Partition mit 20MiB-Blöcken komplett voll. Die Daten bleiben davon unberührt. Es geht nur darum, als gelöscht markierte Sektoren auf NullNull zu setzen. Im Anschluß kann dann der "vmware-vdiskmanager" diese leeren Sektoren aus der VMDK werfen und diese somit einschrumpfen.

[Mr. T]

@Dayworker

Hat deine Platte nicht eine andere Aufteilung ... wenn ich das richtig erlesen habe?

Bei mir wäre /dev/sda2 bzw. /dev/sda5 die große Platte. Die kann ich allerdings nicht mounten. Nach Eingabe von

Code: Alles auswählen

sudo mount /dev/sda2 /media

erhalte ich

Code: Alles auswählen

mount: You must specify the filesystem type

Nach Eingabe von

Code: Alles auswählen

sudo mount -t ext2 /dev/sda2 /media

erhalte ich

Code: Alles auswählen

mount: wrong fs type, bad option, bad superblock on /dev/sda2,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Nach Eingabe von

Code: Alles auswählen

sudo mount /dev/sda5 /media

erhalte ich

Code: Alles auswählen

mount: Unknown filesystem type 'LVM2_member'

Nach Eingabe von

Code: Alles auswählen

sudo mount -t ext2 /dev/sda5 /media

erhalte ich

Code: Alles auswählen

mount: /dev/sda5 already mounted or /media busy

Ich bin grad verunsichert, ob wir alle von derselben Plattenkonstellation ausgehen und will solange nichts ausprobieren.

[JustMe]

Stimmt, wenn Du Deine VM gerade ausfuehrst, brauchst Du sda5 auch nicht zu mounten (sda2 ist nur der Container, eine sog. "Erweiterte Partition" im DOS-Jargon).

Somit sollten diese Befehle fuer Dich massgeschneidert sein: (Gequoted von Dayworker, ergaenzt von mir)
- sudo dd if=/dev/zero of=/tmp/0bits bs=20971520 (schreibt die Datei /tmp/0bits mit 20MiB-Blöcken komplett voll [und damit die Partition sda5, auf der /tmp liegt])
- sudo rm /tmp/0bits (löscht die Datei "/tmp/0bits" wieder)
- VM beenden (Rechtsklick in den Desktop und "Exit" wählen)
- VMDK erneut durch den vmware-vdiskmanager mit -t 0 jagen
- neue VMDK auf Groesse kontrollieren -> sollte jetzt kleiner sein
- falls ja -> freuen
- falls nein -> wirklich Ende fuer mich, weil dann der LVM dazwischenfunkt

[Mr. T]

Code: Alles auswählen

user@ubuntu:~$ sudo dd if=/dev/zero of=/tmp/0bits bs=20971520
dd: writing `/tmp/0bits': No space left on device
778+0 records in
777+0 records out
16309334016 bytes (16 GB) copied, 183.54 s, 88.9 MB/s
user@ubuntu:~$ sudo rm /tmp/0bits
user@ubuntu:~$ sudo df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu-root   19G  3.3G   15G  19% /
udev                     494M  4.0K  494M   1% /dev
tmpfs                    201M  524K  200M   1% /run
none                     5.0M     0  5.0M   0% /run/lock
none                     502M     0  502M   0% /run/shm
cgroup                   502M     0  502M   0% /sys/fs/cgroup
/dev/sda1                228M   26M  190M  12% /boot


Die neue *.vmdk ist jetzt von 12.5GB auf 4.6GB geschrumpft. In den VM-Settings ist unter Hardware die Hard Disk als SCSI mit 20 GB gelistet. In den Details zu diesem Device steht

Capacity
Current size: 4.6 GB
System free: 16.0 GB
Maximum size: 20 GB

Ich dachte, dieser Wert würde sich auch verändern. Wie muss ich das verstehen?

[JustMe]

Das ist so zu verstehen, wie ich es geschrieben habe:
Auf der VMDK koennte man noch immer bis zu diesen 20GB an Daten schreiben, wenn das darunterliegende Host OS Volume (System Free 16GB) nicht irgendwann voller laufen sollte.
20GB max. Groesse minus 4.6GB bereits belegt ergibt 15.4 GB max Zuwachs, welcher kleiner ist als die derzeitigen 16GB System Free.

Schau' einfach in einiger Zukunft und dann regelmaessig mal nach
- wieviel Platz Deine Host OS Partition noch hat
- wie gross die VMDK geworden ist
- wieviel freien Platz df in der VM anzeigt
und wiederhole die nun erfolgreich durchgefuehrten Aufgaben, falls noetig.

Welcher Wert genau sollte sich denn Deiner Meinung nach noch veraendern?
Dass wir (bzw. ich) aufgrund der LVM Problematik die Volumes INNERHALB der VMDK nicht kleiner bekommen, sollte im Laufe des Threads eigentlich klar geworden sein. Das waere auch eher eine Frage an ein Ubuntu-Forum, weil es nichts mit VMware zu tun hat.

[Mr. T]

Welcher Wert genau sollte sich denn Deiner Meinung nach noch veraendern?

die 20 GB

Dass wir (bzw. ich) aufgrund der LVM Problematik die Volumes INNERHALB der VMDK nicht kleiner bekommen, sollte im Laufe des Threads eigentlich klar geworden sein.

Mir noch nicht. Dazu verstehe ich die Zusammenhänge (noch) nicht ausreichend.

Das waere auch eher eine Frage an ein Ubuntu-Forum, weil es nichts mit VMware zu tun hat.

Verstehe und sehe ich genauso.

Trotzdem ein großes DANKE an euch beide für eure geduldige und ausführliche Hilfestellung.

[Dayworker]

Die 20GB kannst du nur manuell kleiner bekommen, wenn du die gesamte VMDK neu erstellst und dann dort wieder entsprechend partitionierst. Eigentlich könnte das ganz einfach werden, wenn man mehr Ahnung von LVM hätte.
Grundsätzlich würde man bzw ich der VM eine zweite VMDK in der gewünschten Zielgrösse verpassen und diese wieder entsprechend auf "boot" und LVM verteilen. Im nächsten Schritt würde ich mit "rsync" die kompletten Dateiinhalte inklu Zugriffsrechte von "boot" und LVM 1:1 rüberkopieren und die jetzt zu grosse VMDK nur aus der VM-Config nur auskommentieren. Den Abschluß würde dann im Booten einer Ubuntu Live-CD bestehen, mit der man per "chroot" ins System mit der neuen Platte wechselt und darin dann den Bootmanager neu schreibt. Dazu muß man dann sicher noch die neue Platten-ID mit sudo blkid ermitteln und in die vorhandene Datei "/etc/fstab" eintragen. Dazu gibts bei den UbuntuUsers aber einen entsprechenden Wiki-Eintrag, den Link dazu hatte ich schon als "Ubuntu_umziehen" gepostet.


Das Problem für JustMe und mich ist, daß wir beide mit LVM bisher nicht in Kontakt gekommen sind. Im Prinzip legt LVM eine zusätzliche Verwaltungsschicht über die Datenträger und gestattet darüber zur Laufzeit ein einfacheres Verkleinern, Anlegen oder Vergrössern eines bestehenden Laufwerkvolumes. Praktisch ist dabei natürlich, daß man einfach weitere Laufwerke zustecken kann und dadurch das bestehende Laufwerksvolume vergrössern oder das vorhandene Volume einfacher in verschieden grosse Teile zerstückeln kann. Das Vergrössern und Verkleinern läßt sich aber auch damit erreichen, indem man die vorhandene Partition vergrössert oder meinetwegen den Mountpunkt "/home" auf ein anderes, kleineres Laufwerk auslagert. Es ist genauso eine Aufteilung denkbar, bei der man das minimale Linux-System auf einer Platte, die Home-Verzeichnisse auf eine weitere und das Webverzeichnis als weiteren Mountpunkt auf eine dritte Platte auslagert. In letzterem Fall könnte man vermutlich sogar die DB mit auf die dritte Platte verlagern und wenn du die VM an zwei Orten nutzt, bräuchte man vermutlich nur noch die Webserver/SQL-VMDK mit sich führen und der VM am jeweiligen Ausführungsort als neuen VMDK-Speicherort angeben. Auf der anderen Seite sind 10GiB auch nicht so viel, um die gesamte VM nicht doch auf Stick oder SD-Karte immer dabei zu haben. Dazu sollten Stick oder Karte aber zumindest über USB2.0 angebunden sein und auch mindestens auf Schreibraten von durchschnittlich 20MiB/s kommen. Darunter wirds sonst echt zäh, bleibt aber machbar.