[gelöst] root-Partition unter LVM vergrößern

bolder · 6 Okt. 2010

Hallo!

Wir haben hier einen virtuellen Server mit SLES 11, der von einer Firma installiert wurde, auf die ich im Moment keinen Zugriff habe. Für eine bestimmte Anwendung (Nagios) muss nun /var vergrößert werden.

Folgende derzeitige Partitionierung ist vorhanden:

Code:

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/hvbg-root
                       40G  3.4G   35G   9% /
udev                  3.9G  104K  3.9G   1% /dev
/dev/sda1             145M   29M  109M  21% /boot
/dev/mapper/hvbg-opt  116G   25G   85G  23% /opt
/dev/mapper/hvbg-var  114G   65G   44G  60% /var
tmpfs                 500M  170M  331M  34% /opt/openitc/nagios/var
srvhvbgkola0013:~ #

Das Verzeichnis /var soll nun von 114 GByte auf 400 GByte vergrößert werden, Plattenplatz im SAN ist vorhanden und der virtuellen Maschine zugewiesen.

Problem ist nun, dass auf /dev/sda3 nicht nur /var und /opt liegen sondern auch das Wurzelverzeichnis /

Möchte ich nun über das Partitionierungstool in YaST /dev/sda3 vergrößern, dann erhalte ich folgende Meldung:

Code:

Partition /dev/sda3 ist in Gebrauch. Ihre Größe kann nicht geändert werden. Um die Größe von /dev/sda3 zu ändern, stellen Sie sicher, dass sie nicht in Benutzung ist.

Ich könnte nun /var und /opt aushängen, aber beim Stammverzeichnis funktioniert das natürlich nicht.

Habe dann versucht, mit Parted Magic dran zu gehen und erhalte die Meldung, dass LVM nicht unterstützt wird.

Also erstes Ziel sollte es sein, die Partition /dev/sda3 zu vergrößern, das bekomme ich aber mit darauf installiertem /-Filesystem nicht hin.
Es wäre auch denkbar, das Wurzelverzeichnis / aus dem LVM zu entfernen - ich weiß aber nicht, wie das geht.

Hat jemand einen Tipp?

spoensche · 6 Okt. 2010

Du kannst die Größe des logischen Volumes /dev/mapper/hvbg-root verkleinern. (Siehe

Code:

man lvresize

) Wenn du 2 virtuelle Festplatten hast kannst du die 2.Platte nicht einer Partition von der ersten Platte zuweisen, was auch bei 2 physikalischen Platten nicht funktioniert.

Du kannst allerdings den Inhalt von /var auf eine Partition der 2. Platten kopieren und die Partition als /var mounten. Das macht man aber per LiveCD statt im Betrieb, weil unter /var z.B. MySQL Datenbanken, die Logfiles, die .pid Files liegen und man sich sonst das System abschießt.

mkossmann · 6 Okt. 2010

Aus deinen Angaben wird nicht klar, ob die Volumegroup voll ist.
Was sagt pvscan ( auf der Kommandozeile) ?
Wenn Sie nicht voll ist, kannst du das logical volume, das für /var benutzt wird, einfach vergrößern.
Wenn Sie voll ist ,kannst du die logical volumes für /opt oder / verkleinern oder mit pvcreate ein weiteres Physical volume auf freien Platz anlegen und mit vgextend der Volumegroup zuordnen. Dann hast du wieder freien Platz in der Volumegroup und kannst wie vor das logical volume vergrößern.

bolder · 7 Okt. 2010

spoensche schrieb:
Du kannst die Größe des logischen Volumes /dev/mapper/hvbg-root verkleinern. (Siehe

Code:

man lvresize

)

Verkleinern von root hatte ich allerdings nicht vor.

spoensche schrieb:
Wenn du 2 virtuelle Festplatten hast kannst du die 2.Platte nicht einer Partition von der ersten Platte zuweisen, was auch bei 2 physikalischen Platten nicht funktioniert.

Ich habe aber nur eine virtuelle Festplatte. Diese wurde von ca. 300 GB auf 600 GB vergrößert, und jetzt habe ich das Problem, die Partition /dev/sda3 an die neue Größe anzupassen.

spoensche schrieb:
Du kannst allerdings den Inhalt von /var auf eine Partition der 2. Platten kopieren und die Partition als /var mounten. Das macht man aber per LiveCD statt im Betrieb, weil unter /var z.B. MySQL Datenbanken, die Logfiles, die .pid Files liegen und man sich sonst das System abschießt.

2. Platte einzurichten ist nicht das Ziel.

mkossmann schrieb:
Aus deinen Angaben wird nicht klar, ob die Volumegroup voll ist.
Was sagt pvscan ( auf der Kommandozeile) ?
Wenn Sie nicht voll ist, kannst du das logical volume, das für /var benutzt wird, einfach vergrößern.
Wenn Sie voll ist ,kannst du die logical volumes für /opt oder / verkleinern oder mit pvcreate ein weiteres Physical volume auf freien Platz anlegen und mit vgextend der Volumegroup zuordnen. Dann hast du wieder freien Platz in der Volumegroup und kannst wie vor das logical volume vergrößern.

pvscan sagt:

Code:

  PV /dev/sda3   VG hvbg   lvm2 [271.84 GB / 4.00 MB free]
  Total: 1 [271.84 GB] / in use: 1 [271.84 GB] / in no VG: 0 [0   ]

Ich sehe das so, dass die Volumegroup voll ist.
Verkleinern von /opt oder / ist nicht das Ziel, ich würde dann den Weg über pvcreate bevorzugen. Da ich überhaupt keine Erfahrung mit LVM habe (ich habe das nicht selbst eingerichtet) weiß ich allerdings nicht wirklich, wie ich mit den Kommandos umgehen soll. Der Server ist produktiv, da möchte ich auch keine langen Ausfälle haben. Kann ich das auch über YaST machen?

spoensche · 9 Okt. 2010

bolder schrieb:
Ich habe aber nur eine virtuelle Festplatte. Diese wurde von ca. 300 GB auf 600 GB vergrößert, und jetzt habe ich das Problem, die Partition /dev/sda3 an die neue Größe anzupassen.

Das kann und wird nicht funktionieren. Für das OS, in der VM ist das reale physische Hardware, also eine reale Festplatte und die kann man nicht einfach vergrößern, da die Größe von den Sektoren, Zylindern abhängig ist.

bolder schrieb:
2. Platte einzurichten ist nicht das Ziel.

Da wirst du aber nicht drum rum kommen, es sei denn du ziehst ein Image von der virtuellen Platte, legst eine neue größere an und packst da das Image wieder drauf.

bolder · 11 Okt. 2010

spoensche schrieb:
Das kann und wird nicht funktionieren. Für das OS, in der VM ist das reale physische Hardware, also eine reale Festplatte und die kann man nicht einfach vergrößern, da die Größe von den Sektoren, Zylindern abhängig ist.

Jetzt verstehe ich gar nichts mehr.
Ich habe schon häufig folgendes gemacht:
vorhanden war ein SLES9-System mit / germountet auf /dev/sda2.
- virtuelle Festplatte im VI-Client von 4GB auf 6 GB vergrößert
- virtuelle Maschine mit ISO-Image von PartedMagic gebootet
- dort wurde dann /dev/sda2 angezeigt und 2 GB unallocated
- mit dem Resize/Move-Button /dev/sda2 auf volle Größe erweitert
- anschließend Reboot des Servers
Also grundsätzlich funktioniert ein Vergrößern der root-Partition schon.....
Ich habe jetzt nur das Problem, dass ein LVM drauf liegt.
Kann ich das denn vielleicht auflösen, sodass ich dann den Weg gehen kann, den ich auch schon früher beschritten habe?

spoensche · 11 Okt. 2010

Du kannst ein LVM auflösen, aber die Datensicherung vorher nicht vergessen.

bolder · 12 Okt. 2010

Danke für den Hinweis, das werde ich probieren.
Datensicherung ist selbstverständlich, die haben wir sowieso. Außerdem werde ich vorher von der VM einen Snapshot ziehen.
Wird eine Weile dauern, da ich erst mal recherchieren muss, wie das ganze so funktioniert. Ich melde mich aber auf jeden Fall mit einem Ergebnis.

Tooltime · 12 Okt. 2010

Ich denke der Grundgedanke von LVM ist noch nicht angekommen, also zuerst einmal ein Blick ins Handbuch (Kapitel 2.2 Seite 53)

http://www.novell.com/de-de/documen...pensuse_reference/book_opensuse_reference.pdf

Na da ist aber schon einiges suboptimal gelaufen, die richtige Vorgehensweise wäre folgendes gewesen:

1. Mit freien Plattenplatz eine neue Partition mit dem Typ LVM anlegen (vorbereiten für LVM).
2. Neue LVM der entsprechenden volumegroup zuordnen (Logische Platte vergrößern).
3. logical volume vergrößern (vergrößert die logische Partition)
4. Filesystem auf logical volume Größe vergrößern

Der Haupteinsatzzweck von LVM liegt genau darin, dieses hier zu vermeiden:

bolder schrieb:
- virtuelle Festplatte im VI-Client von 4GB auf 6 GB vergrößert

Auf einer realen Platte muss man dann alle nachfolgenden Partitionen verschieben.

Was nun? In deinen Fall dürfte folgendes helfen:

# Aktuelle Größe der logischen Platte
vgdisplay /dev/hvbg
# Ganze reale Partition nutzbar machen
pvresize /dev/sda2
# Kontrollieren ob logische Platte Größer ist
vgdisplay /dev/hvbg
# Wenn ja, logische Partition vergrößern (alles nach var)
# Der Parameter -l ist ein kleines L
lvextend -l "100%FREE" /dev/hvbg/var

Wie man das Filesystem vergrößert hängt natürlich vom Filesystem ab. Und natürlich gilt, man page zu den entsprechenden Befehlen durch lesen. Hoffe ich habe mich nichts übersehen, denn normaler Weise mache ich so etwas einfach mit YaST.

bolder · 27 Okt. 2010

Sorry für die späte Antwort - ich war krank.
Der Grundgedanke ist bei mir schon angekommen, und ich habe den entsprechenden Part im Handbuch (allerdings im Server-Handbuch) gelesen bevor ich diesen Thread eröffnet habe.
Das Problem ist, und das hatte ich eingangs geschildert, dass ich die Sache nicht selbst installiert habe, sondern ein Dienstleister. Und dieser hat für meine Begriffe einen großen Fehler begangen, indem er das /-Filesystem in den LVM integriert hat.
Da wir uns in einer virtuellen Umgebung befinden hätte ich ohne LVM gearbeitet, eine extra Partition für /var angelegt und dann die Partition einfach mit VMware-Bordmitteln bzw. GParted erweitert - nun das Kind ist jetzt leider in den Brunnen gefallen.

Ich möchte so wenig Ausfall wie möglich haben und auch nicht durch irgendwelches Rumprobieren verantwortlich sein, dass die Ausfallzeit jetzt doch höher wird. Deshalb habe ich mich mit dem Dienstleister in Verbindung gesetzt und hoffe, dass der sich kostenfrei der Sache annimmt. Bis dahin halte ich die Füße still, melde mich aber auf jeden Fall nochmal mit einem Ergebnis.

Bis dahin Danke an alle für die Hinweise.

spoensche · 28 Okt. 2010

Gut das du wieder Gesund bist.

bolder schrieb:
Und dieser hat für meine Begriffe einen großen Fehler begangen, indem er das /-Filesystem in den LVM integriert hat.

:schockiert: Wo ist da der Fehler? Was sollte daran falsch sein?

bolder schrieb:
Da wir uns in einer virtuellen Umgebung befinden

Für dich ist es eine virtuelle Umgebung, für das OS ist es ein Rechner wie jeder andere auch.

bolder schrieb:
eine extra Partition für /var angelegt und dann die Partition einfach mit VMware-Bordmitteln bzw. GParted erweitert ...
Ich möchte so wenig Ausfall wie möglich haben und auch nicht durch irgendwelches Rumprobieren verantwortlich sein, dass die Ausfallzeit jetzt doch höher wird.

Mit gparted hättest du die Partition nicht im laufenden Betrieb erweitern können, weil Daten auf /var geschrieben werden und dies bei einer Partitionserweiterung zu schwerwiegenden Fehlern und mit sehr hoher Wahrscheinlichkeit zu Datenverlust führt. Bei LVM kannst du das im laufenden Betrieb machen. Du hättest also eine geringere Ausfallzeit.
Ausserdem tätigt man solche Arbeiten i.d.R. erst zu der Zeit, wo die wenigsten Zugriffe stattfinden. Also in der Woche, zur sehr späten Abendzeit (ab 23 Uhr) oder sehr früh morgens (die Aktion ist, bis spätestens 6 Uhr, vollständig durchgeführt.

bolder · 29 Okt. 2010

spoensche schrieb:
bolder schrieb:

Und dieser hat für meine Begriffe einen großen Fehler begangen, indem er das /-Filesystem in den LVM integriert hat.

Zum Vergrößern anklicken....

:schockiert: Wo ist da der Fehler? Was sollte daran falsch sein?

Es verkompliziert die Sache enorm, denn das /-Filesystem ist immer aktiv, d.h. ich kann es nicht aushängen. Wäre nur /var im LVM, dann hätte ich es warscheinlich schon alleine hinbekommen.

spoensche schrieb:
Für dich ist es eine virtuelle Umgebung, für das OS ist es ein Rechner wie jeder andere auch.

Aber es ist in einer virtuellen Umgebung viel leichter, Plattenplatz hinzuzufügen.

spoensche schrieb:
Mit gparted hättest du die Partition nicht im laufenden Betrieb erweitern können, weil Daten auf /var geschrieben werden und dies bei einer Partitionserweiterung zu schwerwiegenden Fehlern und mit sehr hoher Wahrscheinlichkeit zu Datenverlust führt. Bei LVM kannst du das im laufenden Betrieb machen. Du hättest also eine geringere Ausfallzeit.
Ausserdem tätigt man solche Arbeiten i.d.R. erst zu der Zeit, wo die wenigsten Zugriffe stattfinden. Also in der Woche, zur sehr späten Abendzeit (ab 23 Uhr) oder sehr früh morgens (die Aktion ist, bis spätestens 6 Uhr, vollständig durchgeführt.

Ich muss das nicht im laufenden Betrieb machen. Ein Ausfall von einer halben Stunde wäre für mich schon ok, nicht jedoch länger. Ich hätte den Rechner ausgeschaltet und mit GParted /var vergrößert - fertig. Leider wird die Vergrößerung der /-Partition von GParted nicht unterstützt.
Wir haben hier nur Zugang zwischen 6 Uhr und 19 Uhr, somit kann ich solche Dinge nicht zu vernünftigen Uhrzeiten durchführen.

spoensche · 29 Okt. 2010

bolder schrieb:
spoensche schrieb:

bolder schrieb:

Und dieser hat für meine Begriffe einen großen Fehler begangen, indem er das /-Filesystem in den LVM integriert hat.

Zum Vergrößern anklicken....

:schockiert: Wo ist da der Fehler? Was sollte daran falsch sein?

Zum Vergrößern anklicken....

Es verkompliziert die Sache enorm, denn das /-Filesystem ist immer aktiv, d.h. ich kann es nicht aushängen. Wäre nur /var im LVM, dann hätte ich es warscheinlich schon alleine hinbekommen.

Du hast das Grundprinz von LVM nicht verstanden. Bei LVM brauchst du / nicht aushängen sondern kannst im laufenden Betrieb die Änderung durchführen. LVM erleichert dabei die Arbeit. Tooltime hat dir doch die Lösung an die Hand gegeben und wie du siehst, wird da nix ausgehangen.

bolder schrieb:
Ein Ausfall von einer halben Stunde wäre für mich schon ok, nicht jedoch länger.

Eine Partitionsvergrößerung oder Verkleinerung ist immer mit einem gewissen Risiko behaftet und wenn etwas schief geht bist du 100%ig weit über die 30 Min. raus.

bolder schrieb:
Wir haben hier nur Zugang zwischen 6 Uhr und 19 Uhr, somit kann ich solche Dinge nicht zu vernünftigen Uhrzeiten durchführen.

Dein Vorgesetzter wird bei dieser Aktion bestimmt nichts gegen haben, wenn du ausnahmsweise mal später als 19 Uhr vor Ort bist. Du kannst ja den Schlüssel an dich nehmen und ihn dann morgens wieder abgeben.

framp · 29 Okt. 2010

bolder schrieb:
Wir haben hier nur Zugang zwischen 6 Uhr und 19 Uhr, somit kann ich solche Dinge nicht zu vernünftigen Uhrzeiten durchführen.

Da scheint jemand noch nicht verstanden zu haben dass gut Ding will Weile haben

Ich empfehle Dir das in Deinem Kreise deutlich zu machen: Zuverlässige Änderungen benötigen Zeit - vor allen Dingen für Dich - wenn die Produktion sich zu Hause befindet. Wenn Sie Dir keinen Zugang zu den Systemen in der 'alle-zu-hause' Zeit geben ist es einfach nicht möglich etwas zu ändern, ohne dass der ganze Laden betroffen ist.

Das musst Du Deinen Leuten klar machen !

bolder · 16 Nov. 2010

So - hat jetzt etwas länger gedauert aufgrund von organisatorischen Dingen und Prioritätensetzung, aber die Sache ist gelöst.
Nachdem ich zunächst Plattenplatz des SAN der virtuellen Maschine hinzugefügt hatte habe ich eine weitere Partition erzeugt und die vorhandene Volume-Group vergrößert. Dann wollte ich das logische Volume /var vergrößern, erhielt jedoch die Meldung, dass dies gemounted ist und es deshalb nicht geht. Bin dann in den Single-User Mode gegangen und habe /var vergrößert. Alles ok jetzt.

Vielen Dank an alle für die Unterstützung!

Olaf

[gelöst] root-Partition unter LVM vergrößern

bolder

Member

spoensche

Moderator

mkossmann

Member

bolder

Member

spoensche

Moderator

bolder

Member

spoensche

Moderator

bolder

Member

Tooltime

Advanced Hacker

bolder

Member

spoensche

Moderator

bolder

Member

spoensche

Moderator

framp

Moderator

bolder

Member