Erste Hilfe bei zu kleiner root Partition einer VCSA

In jüngster Zeit sehe ich immer wieder vCenter Appliances, die nach Reboot nicht alle Dienste starten können. Ein Blick auf die Shell zeigt häufig eine komplett gefüllte root Partition. Man kann mit einigen Tricks etwas Platz schaffen, aber erhält meist keine nachhaltige Lösung. Die VCSA wurde unter Umständen zu klein dimensioniert. Will man das Problem dauerhaft beseitigen, wird man um eine Vergrößerung der root Partition nicht herum kommen. Das klingt zunächst einfach, ist in der Durchführung etwas heikel.

Prozedur

Device ermitteln

Zunächst gilt es zu ermitteln, auf welchem Device sich die root Partition befindet.

lsblk

vc:~ # lsblk
 NAME MAJ:MIN RM SIZE RO MOUNTPOINT
 sda 8:0 0 20G 0
 ├─sda1 8:1 0 132M 0 /boot
 ├─sda2 8:2 0 1G 0 [SWAP]
 └─sda3 8:3 0 10.9G 0 /
 sdb 8:16 0 1.4G 0
 sdc 8:32 0 25G 0
 └─swap_vg-swap1 (dm-8) 253:8 0 25G 0 [SWAP]
 sdd 8:48 0 50G 0
 └─core_vg-core (dm-7) 253:7 0 50G 0 /storage/core
 sde 8:64 0 10G 0
 └─log_vg-log (dm-6) 253:6 0 10G 0 /storage/log
 sdf 8:80 0 10G 0
 └─db_vg-db (dm-5) 253:5 0 10G 0 /storage/db
 sdg 8:96 0 5G 0
 └─dblog_vg-dblog (dm-4) 253:4 0 5G 0 /storage/dblog
 sdh 8:112 0 25G 0
 └─seat_vg-seat (dm-3) 253:3 0 25G 0 /storage/seat
 sdi 8:128 0 1G 0
 └─netdump_vg-netdump (dm-2) 253:2 0 1016M 0 /storage/netdump
 sdj 8:144 0 10G 0
 └─autodeploy_vg-autodeploy (dm-1) 253:1 0 10G 0 /storage/autodeploy
 sdk 8:160 0 10G 0
 └─invsvc_vg-invsvc (dm-0) 253:0 0 10G 0 /storage/invsvc
 fd0 2:0 1 4K 0
 sr0 11:0 1 1024M 0

Nun müssen wir herausfinden, zu welcher SCSI node sda gehört.

lsscsi

vc:~ # lsscsi
 [0:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
 [0:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb
 [0:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc
 [0:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd
 [0:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
 [0:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf
 [0:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg
 [0:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
 [0:0:10:0] disk VMware Virtual disk 1.0 /dev/sdi
 [0:0:12:0] disk VMware Virtual disk 1.0 /dev/sdj
 [0:0:14:0] disk VMware Virtual disk 1.0 /dev/sdk
 [1:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0

Folglich ist sda auf der ersten VMDK, was auch vom Namen zu erwarten war.

VMDK in den VM Einstellungen vergrößern

Von 11GB (default) auf 20GB vergrößern. Die VM darf hierfür keinen Snapshot haben. LVM und die Autogrow-Funktion greift hier leider nicht.

Damit die größere Disk erkannt wird, benötigt die VM einen Neustart.

shutdown -r now

Disk sda anzeigen

fdisk -l /dev/sda

 

vc:~ # fdisk -l /dev/sda

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: 0x547c469c

Device Boot Start End Blocks Id System
 /dev/sda1 2048 272383 135168 83 Linux
 /dev/sda2 272384 2377727 1052672 82 Linux swap / Solaris
 /dev/sda3 * 2377728 25165823 11394048 83 Linux

sda3 ist durch den Asterisk (*) als startbar markiert.

df -h

 

vc:~ # df -h
 Filesystem Size Used Avail Use% Mounted on
 /dev/sda3 11G 5.1G 5.1G 51% /
 udev 7.9G 164K 7.9G 1% /dev
 tmpfs 7.9G 40K 7.9G 1% /dev/shm
 /dev/sda1 128M 38M 84M 31% /boot
 /dev/mapper/core_vg-core 50G 185M 47G 1% /storage/core
 /dev/mapper/log_vg-log 9.9G 8.7G 695M 93% /storage/log
 /dev/mapper/db_vg-db 9.9G 4.0G 5.4G 43% /storage/db
 /dev/mapper/dblog_vg-dblog 5.0G 2.8G 1.9G 60% /storage/dblog
 /dev/mapper/seat_vg-seat 25G 20G 4.1G 83% /storage/seat
 /dev/mapper/netdump_vg-netdump 1001M 18M 932M 2% /storage/netdump
 /dev/mapper/autodeploy_vg-autodeploy 9.9G 151M 9.2G 2% /storage/autodeploy
 /dev/mapper/invsvc_vg-invsvc 9.9G 297M 9.1G 4% /storage/invsvc

Partition sda3 ist noch nicht vergrößert

Gefahr – Danger – Pericolo !

Bevor wir fortfahren, erstellen wir einen Snapshot der VCSA. Wer Veeam Backup & Replication im Einsatz hat, sollte an dieser Stelle auch ein startbares Replikat erzeugen.

Alle Anweisungen ohne Gewähr und auf eigene Gefahr.

Wir zerstören Partition sda3 und bauen sie sogleich in neuen Grenzen wieder auf. Wenn hier etwas schief geht, ist das vCenter verloren. Lies den letzten Satz noch einmal.

Partition sda3 löschen

fdisk /dev/sda

Die Partition /dev/sda3 wird mit dem Delete-Befehl [d] und anschliessender Spezifizierung der Partition [3] gelöscht.

Command (m for help): d

Partition number: 3

Die Partitionstabelle ist noch nicht geschrieben. D.h. man könnte mit Ctrl-C noch abbrechen.

Partition neu erstellen

Es wird eine neue Partition erzeugt [n]. Der Typ ist primary [p]. Die vorgeschlagene Partitionsnummer [3]. Ab hier alle Default-Werte übernehmen.

Command (m for help): n

Command action
e extended
p primary partition (1-4)

p
3

Partition sda3 bootfähig machen

Die neue Partition sda3 ist noch nicht bootfähig. Das erledigen wir jetzt, indem wir das bootable flag setzen [a] und Partition [3] wählen.

Command (m for help): a

Partition number (1-4): 3

Kontrolle der Partitions-Tabelle

Mit dem print-Befehl [p] können wir die Einstellungen nochmas kontrollieren.

Command (m for help): p

Partitionstabelle schreiben

Mit dem Write-Befehl [w] schreiben wir die Änderungen in die Partition-Table.

Command (m for help): w

Ein Neustart ist nötig um die Änderung zu übernehmen

shutdown -r now

Nach Neustart wieder per SSH oder Konsole verbinden.

Das Filesystem hat noch die alte Größe. Lediglich die Partition ist vergrößert. Wir passen dies mit dem resize2fs Befehl an.

resize2fs /dev/sda3

Filesystem überprüfen

df -h /dev/sda3

Letzter Schritt

Wenn alles funktioniert darf der Snapshot nicht vergessen werden.