Archiv verlassen und diese Seite im Standarddesign anzeigen : LVM - pvcreate - Partitionen vs ganze HDDs
Acid-Beatz
2016-01-21, 22:45:27
Guten Abend zusammen,
nachdem ich mir heute den LVM mal wieder etwas näher angesehen und einige Sachen ausprobiert habe, bin ich auf folgende Frage gestoßen, für die ich leider keine befriedigende Antwort finden konnte:
In mehreren Tutorials machen sich die Verfasser die Mühe, eine Disk zu erst mit fdisk (Parameter 8e) als LVM-Volume zu labeln, um sie anschließend mit pvcreate /dev/sdc1 /dev/sdd1 [...] ebenfalls für den LVM Gebrauch zu kennzeichnen.
Man-Page:
pvcreate initializes PhysicalVolume for later use by the Logical Volume Manager (LVM). Each PhysicalVolume can be a disk partition, whole disk, meta device, or loopback file
Daraus folgend und für mich die intuitive Lösung:
pvcreate /dev/sdc /dev/sdd [...]
Hat hier jemand eine Idee, was der Hintergrund für diese Partitionierung ist - evtl. Altlasten? Gefunden habe ich diese Vorgehensweise allerdings in mehreren "Hilfeseiten" und Tutorials.
Wenn man noch einen Schritt weiter geht, dann hat man bei einer späteren Vergrößerung der HDD noch das Problem, dass die Partition auch vergrößert werden muss - sehe ich das auch richtig (Anwendungsfall in einer VM)?
Vielen Dank für Eure Antworten
EPIC_FAIL
2016-01-22, 13:48:16
--> http://unix.stackexchange.com/questions/76588/what-is-the-best-practice-for-adding-disks-in-lvm
Using the whole disk as a PV (as opposed to a partition spanning the whole disk) is not recommended because of the management issues it can create. Any other OS that looks at the disk will not recognize the LVM metadata and display the disk as being free, so it is likely it will be overwritten. LVM itself will work fine with whole disk PVs.
Scheint also nur wirklich "problematisch" zu sein, falls man mit anderen OS auf dem gleichen Rechner arbeitet. Aber prinzipiell muss der LVM-Diskriptor auch auf einer RAW-Platte verfügbar sein, d.h. auch auslesbar sein. Wenn man aufpasst, dürfte eigentlich nix passieren. Es ist ja die eigene Schuld, wenn man eine Festplatte ohne Partitionen als "leer" betrachtet...
Birdman
2016-01-22, 21:40:13
Ich nehme auch meistens die ganze Disk und arbeite nur dann mit Partitionen wenn es nicht anders geht.
Lokadamus
2016-01-22, 22:42:27
Daraus folgend und für mich die intuitive Lösung:
Hat hier jemand eine Idee, was der Hintergrund für diese Partitionierung ist - evtl. Altlasten? Gefunden habe ich diese Vorgehensweise allerdings in mehreren "Hilfeseiten" und Tutorials.Du hast wohl diese Hilfsseite gefunden. http://linux.die.net/man/8/pvcreate
Demnach geht es wie bei jeder Einrichtung darum, dass die Partitionen zur Verfügung gestellt werden. Ich will schließlich nicht mein NTFS bzw. *BSD- Partition für LVM zur Verfügung stellen und der kurzen Beschreibung nach werden bestimmte Partitionen ignoriert bzw. angeboten, diese zu formatieren.
Acid-Beatz
2016-01-24, 17:58:52
Guten Tag zusammen,
ich habe bei meiner ursprünglichen Nachricht vergessen zu schreiben, dass ich von einem Linux-Only System ausgehe - Betriebssystemfremde Filesysteme sind sowieso so eine Sache :rolleyes:
Das wars auch schon, Danke für Eure Antworten!
Wenn man noch einen Schritt weiter geht, dann hat man bei einer späteren Vergrößerung der HDD noch das Problem, dass die Partition auch vergrößert werden muss - sehe ich das auch richtig (Anwendungsfall in einer VM)?
Korrekt. Genau aus dem Grund verwende ich seit vielen Jahren nur noch LVMs. Windows-VMs sind hier deutlich einfacher zu handhaben, wenn man nachträglich virtuellen Partitionen in der VM verwenden. LVMs mindern das Problem etwas, lösen es aber nicht vollständig. Man muß immer noch unter Linux eine Partition zerstören, und mit den angepaßten Größen neu anlegen. Bisher ging das glücklicherweise immer gut, birgt aber immer das Risiko des Datenverlustes. Die Grundidee dahinter, logische Partitionen mit VolumeGruppen entsprechen leichter zu verwalten, ist in Linux nicht ganz so gut umgesetzt, das funktioniert beispielsweise mit AIX besser, da hier ohne weiteres logische Gruppen in den Größen leichter angepaßt werden können.
Acid-Beatz
2016-01-25, 23:49:23
Man muß immer noch unter Linux eine Partition zerstören, und mit den angepaßten Größen neu anlegen.
Welchen "Fall" hast du hierbei genau im Kopf?
An die Stelle einer Partition rückt ja das LV, das ich über lvextend innerhalb der VG vergrößern kann.
Wäre noch der Fall, dass ich eine Partition verkleinern will, wobei ich zu erst das Filesystem verkleinere und anschließend das LV, dann steht der Platz in der VG wider zur Verfügung oder übersehe ich da gerade was:confused:
Also, alle Beispiele, die ich im Netz zu nachträglicher Erweiterung des virtuellen Filesystems in einer VM finde (und auch funktionieren ;) ), löschen per f/gdisk oder parted die primären und logischen Partitionen, und erzeugen sie mit den angepaßten Blockgrößen neu.
Ich spreche jetzt nicht davon, über eine weitere Volume Group oder hinzugefügte Partition indrekt ein Filesystem zu vergrößern, sondern wirklich die physische Partition entsprechend anzupassen, so daß sie größer wird, wenn man sie nachträglich erweitert. Wie gesagt, mit einer Windows-VM ist das sehr einfach zu machen, unter Linux nicht so ganz.
Hallo Acid-Beatz,
wenn es dir möglich ist, nimm am Besten einfach die komplette Disk. Wenn sich irgendwann die Größe ändert (z.B. Vergrößerung der LUN oder Disk in VMware), ist es online möglich den "pvresize" durchzuführen und dann den Plattenplatz zu nutzen. Ansonsten bleibt zu meist nur ein Reboot, damit der Kernel die neue Partitionsgröße ermitteln kann. Normalerweise geht der ioctl schief, wenn da noch der Device Mapper (bspw. Multipath oder LVM2) auf einer Partition hängt.
Bei Vergrößerungen oder Verkleinerungen von Logical Volumes kannst du auch direkt den Parameter "-r" (resize) nutzen (siehe "man lvextend" oder "man lvreduce"). Dann wird bspw. bei einem lvreduce das ext4-FS automatisch abgehängt, deinen Vorgaben entsprechend verkleinert und anschließend wieder gemountet.
Alle Lösungen hier arbeiten mit fdisk/gdisk und dem Löschen der Partition mit anschließendem neu anlegen mit den geänderten Größen
https://maanasroyy.wordpress.com/2012/06/03/resize-a-linux-vm-lvm-disk-in-xenserver/
http://support.citrix.com/article/CTX125405
http://serverfault.com/questions/401983/resize-base-xenserver-6-0-partition
http://thingsandstuff.devide.ch/?p=72
Wenn das auch anders und besser ginge, würde ich mich um eine Info freuen.
Acid-Beatz
2016-01-26, 18:43:31
Hey PHuV,
ich bin mir nicht ganz sicher, ob wir von dem gleichen Sachverhalt reden - ich versuche mich mal zu erklären:
Du hast eine 10TB Daten-Disk, die unter /dev/sdc hängt - diese Disk ist anschließend direkt mit mkfs.xfs /dev/sdc
formatiert worden.
Du kannst nun unter VMware/Citrix/... hergehen und diese Disk auf 20TB vergrößern.
(Edit: Citrix/XEN lasse ich jetzt mal mit einem Fragezeichen stehen, weil ich hier schon viele "Besonderheiten" erlebt habe)
Nun musst Du unter Linux den SCSI-Bus neu scannen, damit er die Vergrößerung erkennt - mit der 0 hinter Host musst du rumspielen, damit du die richtige Platte triffst, hier fehlt mir (noch?) die Logik dahinter:
echo "- - -" > /sys/class/scsi_host/host0/scan
WENN das zu vergrößernde Volume dabei war, dann siehst Du mit
fdisk -l
schon die vergrößerte Festplatte und kannst sie anschließend direkt (gemounted!) mit
xfs_growfs /dev/sdc vergrößern.
Das wars.
Mein VMware Player unterstützt leider keine Vergrößerung der Disks im Betrieb, damit ich dir gleich ein Ja oder Nein liefern kann aber ansonsten kann ich es gerne morgen in der Arbeit noch mal versuchen (wenn Du jetzt nicht komplett etwas anderes gemeint hast?) :confused:
Mit xfs mag das so funktionieren. Mit VMWare, Xen und VirtualBox kannst Du mit dem Dateisystem ext3/4 nicht so vorgehen. Aus irgend einen Grund bekommen die VMs unter Linux es nicht mit, wenn sich die Platte vergrößerte. Deshalb erscheint mir der Trick mit fdisk einleuchtend, weil hier das OS gezwungen wird, die Festplattengeometrie neu einzulesen und dann die neuen Blockgrößen in die MBR eingetragen werden.
Ich hab jetzt auch erst heute beim Bauen eines neuen Datenbankservers rausgefunden, daß man bei aktuellen Linuxen ohne Partitionieren per LVM direkt HDD-Devices mounten kann. :redface:
Bisher kann ich nur den Weg:
Anlegen von Primären/Erweiterten Partitionen mit gdisk, fdisk und parted
Partitionstyp angeben, z.B, 83 für Linux-FS
Werte in die MBR oder neu, GPT schreiben
Filesystem mit mkfs.nnn erzeugen
Filesystem mit vorher erzeugtem Mountpoint mounten
Bei AIX lernte ich dann, mit Volumeggroups und logischen Partitonen umzugehen, ohne irgendwelches Partitionsgedöns.
Bei Linux war das immer so ein Mischmasch, und ich habe hier bisher auch immer vorher Partitioniert, weil es in vielen Anleitungen so drinsteht:
Anlegen von Primären/Erweiterten Partitionen mit gdisk, fdisk und parted
Partitionstyp 8e für LVM angeben
Werte in die MBR oder neu, GPT schreiben
Volumegroup anlegen über Partition, z.B. /dev/sdb1
Logisches Volume über die Volumegroup
mkfs auf das logische Volume
Filesystem über /dev/Volumegroup/LogischesVol mit vorher erzeugtem Mountpoint mounten
Tja, mit LVM kann man direkt das ganze Laufwerk /dev/sdb als Partion mit pvcreate /dev/sdb anlegen. Interessant, daß Du auch die Platte direkt ohne Partition verwendest.
Mein Beispiel bezog sich auf solch eine Konstellation:
Disk /dev/hdb: 64 heads, 63 sectors, 621 cylinders
Units = cylinders of 4032 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 * 1 184 370912+ 83 Linux
/dev/hdb2 185 368 370944 82 Linux swap
/dev/hdb3 369 552 370944 83 Linux
Nehmen wir an, /dev/hdb3 sei der Root-Knoten oder irgend ein verwendetes Volume, und nun erweiterst Du in der VM die virtuelle Disk. Wie gesagt, in einer WindowsVM taucht hinten der neue Plattenplatz auf, per diskmgmt.msc einfach die hintere Partition, z.B. C:\ vergrößern, fertig. Unter Linux geht das nicht so einfach. Selbst mit Tools wie GParted klappt das meiner Erfahrung nach nicht immer zuverlässig. Was bisher dagegen immer geklappt hatte, wenn /dev/hdb3 Typ LVM ist, und ich dann einfach per fdisk die letzte Partition lösche, neu anlege, und dann einfach den letzten Block automatisch finden lasse, der dann logischerweise größer als der vorherige ist. Dann wieder wieder vgcreate und lvcreate genau die gleiche VolumeGroup/Logisches Volume anlegen, und schwupps, die Daten sind noch drauf, nur die Platte hat nun noch mehr Platz.
drdope
2016-01-26, 23:02:00
Korrekt. Genau aus dem Grund verwende ich seit vielen Jahren nur noch LVMs. Windows-VMs sind hier deutlich einfacher zu handhaben, wenn man nachträglich virtuellen Partitionen in der VM verwenden. LVMs mindern das Problem etwas, lösen es aber nicht vollständig. Man muß immer noch unter Linux eine Partition zerstören, und mit den angepaßten Größen neu anlegen.
Wenn du die alte, virtuelle HDDs erhalten willst, kannst du auch einfach eine neue, virtuelle HDD in der VM anlegen und mit pvmove (http://linux.die.net/man/8/pvmove) den Inhalt von der alten "HDD" zur neuen "HDD" migrieren.
Ja, das ist mir klar, das ist ja der Vorteil, wenn man mit Volumegroups arbeitet, da kann man ja beliebig viele Platten oder Partitionen hinzufügen.
In Deinem Fall hat es nur den Nachteil, daß Du eine zusätzliche virtuelle Platte anlegen mußt, und das will man ja nicht unbedingt immer. Du siehst dann von außen als Admin dann nicht unbedingt in dem Client, wo welche Platte dann verwendet wird. Wenn dann so ein Dödel auf die Idee kommt, eine zusätzliche Platte wegzulöschen, macht das die ganze VM u.U. kaputt (Ja, ist wirklich schon so passiert). Weiterhin hast Du - wie bei dynamischen Datenträger unter Windows - das Problem, daß Du nie weißt, wo nun genau Deine Daten liegen, wenn Du das über mehrere Platten verteilst.
Ich mags lieber übersichtlich und einheitlich logisch, und teile einer Platte oder einem Volume eine physikalische/virtuelle Disk zu. ;) Gut, ist zugegeben vielleicht nicht die optimalste Lösung und Strategie.
Acid-Beatz
2016-01-26, 23:33:25
Guten Abend!
In Deinem Fall hat es nur den Nachteil, daß Du eine zusätzliche virtuelle Platte anlegen mußt, und das will man ja nicht unbedingt immer. Du siehst dann von außen als Admin dann nicht unbedingt in dem Client, wo welche Platte dann verwendet wird
Jein, wenn du ein bisschen Dokumentationsaufwand nicht scheust, dann holst du dir die UUID und trägst sie in die fstab ein, bzw bin ich mir gerade nicht sicher, ob die PVs in den VGs nicht sowieso darüber angesprochen werden - würde Sinn machen.
Den Rest versuche ich morgen zu beantworten nur soviel sei schon mal gesagt, mit an Sicherheit grenzender Wahrscheinlichkeit habe ich das auch schon mit ext3/4 gemacht.
Mit xfs mag das so funktionieren. Mit VMWare, Xen und VirtualBox kannst Du mit dem Dateisystem ext3/4 nicht so vorgehen. Aus irgend einen Grund bekommen die VMs unter Linux es nicht mit, wenn sich die Platte vergrößerte. Deshalb erscheint mir der Trick mit fdisk einleuchtend, weil hier das OS gezwungen wird, die Festplattengeometrie neu einzulesen und dann die neuen Blockgrößen in die MBR eingetragen werden.
Das liegt daran, dass der ioctl nicht durchgeht, weil der Device-Mapper noch auf dem Gerät hängt. Du kannst versuchen, mittels "partprobe" die Kerneldaten aktualisieren zu lassen. Normalerweise hilft aber nur ein Reboot, wenn du Partitionen einsetzt.
Es liegt auf jeden Fall nicht an xfs, das geht mit ext2/3/4 genauso. Vielleicht kannst du mit Befehlt, den Acid-Beatz genannt hatte (echo "- - -" > /sys/class/scsi_host/host<nr.> /scan) die Disks neu einlesen lassen. Bei Systemen mit systemd ist dies normalerweise nicht mehr nötig.
Bei Linux war das immer so ein Mischmasch, und ich habe hier bisher auch immer vorher Partitioniert, weil es in vielen Anleitungen so drinsteht:
Anlegen von Primären/Erweiterten Partitionen mit gdisk, fdisk und parted
Partitionstyp 8e für LVM angeben
Werte in die MBR oder neu, GPT schreiben
Volumegroup anlegen über Partition, z.B. /dev/sdb1
Logisches Volume über die Volumegroup
mkfs auf das logische Volume
Filesystem über /dev/Volumegroup/LogischesVol mit vorher erzeugtem Mountpoint mounten
Tja, mit LVM kann man direkt das ganze Laufwerk /dev/sdb als Partion mit pvcreate /dev/sdb anlegen. Interessant, daß Du auch die Platte direkt ohne Partition verwendest.
Die Vorgehensweise ist ja auch normalerweise in Ordnung, z.B. für eine Disk, auf der das /boot- und ggf. /boot/efi-Dateisystem mit drauf liegt, benötigt man eine Partitionierung.
Mein Beispiel bezog sich auf solch eine Konstellation:
Disk /dev/hdb: 64 heads, 63 sectors, 621 cylinders
Units = cylinders of 4032 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 * 1 184 370912+ 83 Linux
/dev/hdb2 185 368 370944 82 Linux swap
/dev/hdb3 369 552 370944 83 Linux
Nehmen wir an, /dev/hdb3 sei der Root-Knoten oder irgend ein verwendetes Volume, und nun erweiterst Du in der VM die virtuelle Disk. Wie gesagt, in einer WindowsVM taucht hinten der neue Plattenplatz auf, per diskmgmt.msc einfach die hintere Partition, z.B. C:\ vergrößern, fertig. Unter Linux geht das nicht so einfach. Selbst mit Tools wie GParted klappt das meiner Erfahrung nach nicht immer zuverlässig. Was bisher dagegen immer geklappt hatte, wenn /dev/hdb3 Typ LVM ist, und ich dann einfach per fdisk die letzte Partition lösche, neu anlege, und dann einfach den letzten Block automatisch finden lasse, der dann logischerweise größer als der vorherige ist. Dann wieder wieder vgcreate und lvcreate genau die gleiche VolumeGroup/Logisches Volume anlegen, und schwupps, die Daten sind noch drauf, nur die Platte hat nun noch mehr Platz.
Wozu genau der vgcreate und lvcreate - die hast du doch gar nicht gelöscht? Der Kernel sollte auch die Daten behalten? Und auch swap würde ich im LVM halten, imho. So ist das doch viel zu statisch.
Was ich verstehe, ist die Partition zu vergrößern durch Löschen und Neuanlegen. Dann geht aber wahrscheinlich der ioctl schief (s.o.), dann entweder mit Partprobe oder Reboot die Daten im Kernel aktualisieren. Danach kannst du mit pvresize dem LVM kenntlich machen, dass sich die Diskgeometrie geändert hat. Und schon hast du in der Volueme Group mehr Platz zur Verfügung.
In dem Fall würde ich aber eher eine zweite Disk ans System hängen und der Volume-Group zuweisen ohne Partitionierung. Dann erhälst du automatisch alle genannten Vorteile.
Weiterhin hast Du - wie bei dynamischen Datenträger unter Windows - das Problem, daß Du nie weißt, wo nun genau Deine Daten liegen, wenn Du das über mehrere Platten verteilst.
Das ist ja nun mal überhaupt nicht wahr. Man kann im LVM stets herausfinden, auf welchem PV sich welches Extend gerade befindet.
Nachtrag - zum Beispiel:
# pvs --segments -o+lv_name,seg_start_pe,segtype
PV VG Fmt Attr PSize PFree Start SSize LV Start Type
/dev/sda3 centos lvm2 a-- 31.25g 8.25g 0 256 root 0 linear
/dev/sda3 centos lvm2 a-- 31.25g 8.25g 256 256 home 0 linear
/dev/sda3 centos lvm2 a-- 31.25g 8.25g 512 2048 usr 0 linear
/dev/sda3 centos lvm2 a-- 31.25g 8.25g 2560 1024 var 0 linear
/dev/sda3 centos lvm2 a-- 31.25g 8.25g 3584 512 swap 0 linear
/dev/sda3 centos lvm2 a-- 31.25g 8.25g 4096 1792 root 256 linear
/dev/sda3 centos lvm2 a-- 31.25g 8.25g 5888 2112 0 free
@Gast
Danke für die Tipps, das werde ich glatt mal testen, wenn ich etwas Luft hier habe.
Das ist ja nun mal überhaupt nicht wahr. Man kann im LVM stets herausfinden, auf welchem PV sich welches Extend gerade befindet.
Wie meinst Du das genau? Ich meinte, daß Du bei dynamischen Datenträgern im allgemeinen nicht siehst, wo gerade welche Daten abgespeichert oder verteilt werden. Das heißt, Du kannst nicht einfach mal so ein dynamisches dazugebundenes Volume abhängen oder wegmachen, ohne einen Datenverlust zu riskieren. Man muß es so verstehen, daß ich eben vor Ort bei Kunden bin, die das mal so oder so handhaben, und meine Wenigkeit die damit verbundenen Probleme erst mal gerade biegen muß.
Idealerweise hat man ja hinten als Datenträger ein EMC-Schrank oder ein IBM Fibrechannel Storage oder von SUN etc., wo dann eh egal ist, wie die Filesysteme angelegt werden, da die Storage-Systeme sich selbst um Parität, Redunanz etc kümmern.
Hallo PHuV,
das war auf deine Aussage gemünzt, dass man nie wisse, wo die Daten auf den verschiedenen Platten liegen, wenn eine Volume Group mehrere PVs beinhaltet. Habe noch nicht mit Windows' dynamischen Datenträgern rumgespielt, kann aber gut sein, dass man es dort nicht herausbekommt. Beim LVM2 geht das aber, wie gezeigt.
Deswegen noch das Beispiel als Nachtrag (leider nur mit einer Disk - kann aber auch gerne eine zweite hinzufügen und ein paar Extends auf die zweite Disk verschieben). Dort sieht man jedes LV auf der Disk und auch wo sich die Extends befinden. Man kann dort auch sehen, dass das Root-Volume einmal vergrößert wurde von 256 PEs auf 2048 PEs (256+1792=2048), was bei einer Standard-PE-Size von 4MB genau 8GB ergibt.
pvs --segments -o+lv_name,seg_start_pe,segtype
PV VG Fmt Attr PSize PFree Start SSize LV Start Type
/dev/sda3 centos lvm2 a-- 31.25g 8.25g 0 256 root 0 linear
/dev/sda3 centos lvm2 a-- 31.25g 8.25g 4096 1792 root 256 linear
Man kann sich das auch von der anderen Seite betrachten:
# lvdisplay -m centos/root
--- Logical volume ---
LV Path /dev/centos/root
LV Name root
VG Name centos
LV UUID Jy9aJf-vJKC-w29A-l9vo-Os9d-xlvX-VOhy1n
LV Write Access read/write
LV Creation host, time localhost, 2016-01-20 15:47:41 +0100
LV Status available
# open 1
LV Size 8.00 GiB
Current LE 2048
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 8192
Block device 253:0
--- Segments ---
Logical extents 0 to 255:
Type linear
Physical volume /dev/sda3
Physical extents 0 to 255
Logical extents 256 to 2047:
Type linear
Physical volume /dev/sda3
Physical extents 4096 to 5887
Viele Grüße.
Ich hatte erst jetzt deinen Edit gesehen:
Wie meinst Du das genau? Ich meinte, daß Du bei dynamischen Datenträgern im allgemeinen nicht siehst, wo gerade welche Daten abgespeichert oder verteilt werden. Das heißt, Du kannst nicht einfach mal so ein dynamisches dazugebundenes Volume abhängen oder wegmachen, ohne einen Datenverlust zu riskieren.
Die Aussage verstehe ich nicht. Vielleicht kannst du das etwas detaillierter spezifizieren.
Wenn im LVM eine Disk offline geht (und du keinen LVM-Mirror einsetzt), geht i.d.R. die ganze Volume Group offline.
Idealerweise hat man ja hinten als Datenträger ein EMC-Schrank oder ein IBM Fibrechannel Storage oder von SUN etc., wo dann eh egal ist, wie die Filesysteme angelegt werden, da die Storage-Systeme sich selbst um Parität, Redunanz etc kümmern.
Im Enterprise-Umfeld sollte es an einem Storagesystem nicht mangeln. Eine daraus geschnittene LUN kannst du aber analog zu einem VMDK unter VMware ESXi ggf. dynamisch vergrößern. Online (d.h. ohne Reboot) diese Vergrößerung der LUN als Physical Volume (PV) eingesetzt geht aber garantiert nur, wenn du auf die nicht benötigten Partitionen verzichtest.
Acid-Beatz
2016-01-27, 19:23:25
Vielleicht kannst du mit Befehlt, den Acid-Beatz genannt hatte (echo "- - -" > /sys/class/scsi_host/host<nr.> /scan) die Disks neu einlesen lassen. Bei Systemen mit systemd ist dies normalerweise nicht mehr nötig.
Der Befehl funktioniert definitiv - ursprünglich bin ich zu ihm gekommen, weil man in einer virtualisierten Umgebung neu eingebundene Disks ohne Reboot erkennen kann.
Wie gesagt, das genaue Muster um gezielt eine neu angeschlossene oder vergrößerte Device zu treffen fehlt mir noch - Leute mit Ahnung sollen sich hier gerne angesprochen fühlen ;)
System.d hat meiner Erfahrung nach hier keinen Einfluss, wie kommst du darauf?
Idealerweise hat man ja hinten als Datenträger ein EMC-Schrank oder ein IBM Fibrechannel Storage oder von SUN etc., wo dann eh egal ist, wie die Filesysteme angelegt werden, da die Storage-Systeme sich selbst um Parität, Redunanz etc kümmern.
Nur für mich zum verstehen: Du redest von einem FC-Storage, der den Speicher an den Virtualisierer übergibt oder redest du von VMs/Hardware, die ihren Speicher direkt über FC/LUNs bereitgestellt bekommen?
Birdman
2016-01-27, 19:23:40
Mit xfs mag das so funktionieren. Mit VMWare, Xen und VirtualBox kannst Du mit dem Dateisystem ext3/4 nicht so vorgehen. Aus irgend einen Grund bekommen die VMs unter Linux es nicht mit, wenn sich die Platte vergrößerte.
Das geht unter VMWare und Xen (oder auch physischen Systemen) durchaus:
1) echo 1 > /sys/class/scsi_device/x:x:x:x/device/rescan
2) mit fdisk partitione(n) löschen und in der gewünschten Grösse neu erstellen
3) partprobe /dev/sdx
4) resize2fs /dev/sdx1
Acid-Beatz
2016-01-27, 19:38:51
Das geht unter VMWare und Xen (oder auch physischen Systemen) durchaus:
1) echo 1 > /sys/class/scsi_device/x:x:x:x/device/rescan
2) mit fdisk partitione(n) löschen und in der gewünschten Grösse neu erstellen
3) partprobe /dev/sdx
4) resize2fs /dev/sdx1
Wenn du keine Partitionen hast, dann bekommt es die verwaltende Schicht sofort mit, so bald du den SCSI-Bus scannst - das "hängt" alles irgendwo zwischen SCSI-Protokoll und Kernel.
1) echo 1 > /sys/class/scsi_device/x:x:x:x/device/rescan
Darf man aus Linux-technischer Sicht fragen, was der Befehl im Vergleich zu meinem anders macht? (Soll kein Angriff sein, den von mir genannten Befehl habe ich in RH-Dokus gefunden. Lustigerweise preisen sie auch ein Tool (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/rescan-scsi-bus.htmlh --help.) an, das genau das bewirken sollte, bei mir aber nicht funktioniert (CentOS).
Wie gesagt, das genaue Muster um gezielt eine neu angeschlossene oder vergrößerte Device zu treffen fehlt mir noch - Leute mit Ahnung sollen sich hier gerne angesprochen fühlen
System.d hat meiner Erfahrung nach hier keinen Einfluss, wie kommst du darauf?
@System.d: Meiner Erfahrung nach (SLES12, RHEL7, CentOS7,...) erkennt der Kernel direkt, wenn ein neues Gerät angeschlossen wurde (zumindest unter virtualisierten Umgebungen - z.B. ESXi) - die Disk wird sofort angezeigt ohne Rescan der einzelnen SCSI-Hosts. Da ich gerade kein System mit HBA und FC-Storage greifbar habe, kann ich dafür nicht verifizieren. Zur Not kann man immer noch das bereits genannte Skript "rescan-scsi-bus.sh" aus den "sg3-utils" verwenden, sollte es dort nicht der Fall sein.
Wenn die lsscsi installiert hast (alternativ per "cat /proc/scsi/scsi"), kannst du dir anschauen, welcher Corntroller, welcher Bus, welches Target und welche LUN eine Disk hat:
lsscsi
[2:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sda
Das "- - -" beim von dir genannten "echo '- - -' > /sys/class/scsi_host/host#/scan steht hierbei als Wildcard für jeden Channel (Bus), jedes Target und jede LUN. Also in meinem Beispiel würdes du mit
## Achtung: host2
echo 0 0 0 > /sys/class/scsi_host/host2/scan
genau die Disk an Controller 2, Bus 0, ... scannen.
Nachfolgend noch einmal eine mögliche Vorgehensweise:
1. Änderung der Diskgröße in VMware oder auf LUN-Basis
2. Rescan der Disk-Geometrie (sollte mit fstab -l sichtbar werden)
for dev_rescan in `ls /sys/class/scsi_device/*/device/rescan` ; do echo 1 > $dev_rescan; done
3. Neue Partition mit FDisk erzeugen (aus dem freien Speicherplatz)
Eventuell kann man die Partition per "partprobe" oder
partx -a /dev/sda
oder Reboot erkennen lassen
4. ein neues PV erzeugen
pvcreate /dev/sda3 #(change it to the name of new partition)
4. VG erweitern
vgvgextend yourvgname /dev/sda3 #(change it to the name of new partition)
5. Erweitern des LV (vgdisplay oder vgs zeigt den Free-Space an), z.B. um 20 GB (ggf. Parameter -r für automatischen Resize des Filesystems)
lvextend -L+20G /dev/yourvgname/yourlvname
6. Filesystem vergrößern
resize2fs /dev/yourvgname/yourlvname
7. schauen, ob es vergrößert wurde (df oder mount)
Nur für mich zum verstehen: Du redest von einem FC-Storage, der den Speicher an den Virtualisierer übergibt oder redest du von VMs/Hardware, die ihren Speicher direkt über FC/LUNs bereitgestellt bekommen?
Beides. ;) Der Virtualiserer sieht nur Plattenspeicher, weiß aber nicht, wie dieser zusammengesetzt ist, darum kümmert sich das System bzw. die Storageverwaltung selbst. Sprich, ob die Platten gestrippt und gespiegelt, wieviele Platten redundant gesteckt sind, ob da noch ein anderes Filesystem darunterliegt, bekommen die Betriebssysteme nicht mit. Für sie ist einfach nur HDD-Speicher vorhanden und ansprechbar.
Das geht unter VMWare und Xen (oder auch physischen Systemen) durchaus:
1) echo 1 > /sys/class/scsi_device/x:x:x:x/device/rescan
2) mit fdisk partitione(n) löschen und in der gewünschten Grösse neu erstellen
3) partprobe /dev/sdx
4) resize2fs /dev/sdx1
Siehe Dein Punkt 2, davon rede ich doch die ganze Zeit. Man muß mit fdisk ran, und die Partition vorher lösen! Und meine Frage war nur, ob man das auch ohne Löschen der Partition nachträglich eine erweitern kann, so wie eben in Windows und Windows Server.
Birdman
2016-01-28, 12:32:02
Siehe Dein Punkt 2, davon rede ich doch die ganze Zeit. Man muß mit fdisk ran, und die Partition vorher lösen! Und meine Frage war nur, ob man das auch ohne Löschen der Partition nachträglich eine erweitern kann, so wie eben in Windows und Windows Server.
Und Du bist sicher dass unter Windows nicht auch gelöscht und neu erstellt wird, dieser Schritt aber halt einfach hinter GUI und/oder CLI "versteckt" ist?
Du kannst unter Linux auch eines der GUI basierten Tools verwenden, damit kann die Partition ebenfalls aufgezogen werden ohne dass man diese vorher löschen muss.
Kannst auch via Hex-Editior in der MBR PartitionTable rumfummeln und den Endsektor umstellen - ohne vorher was zu löschen.
fdisk ist halt nunmal asbach-uralt und featuremässig seit Jahrzenten nicht mehr wirklich erweitert worden. Daher verwundert es mich nicht dass ein direktes aufziehen einer Partition nicht unterstützt wird, vor allem wenn man das selbe mit ganz wenig mehr Aufwand via löschen und neu erstellen auch erreichen kann.
Und Du bist sicher dass unter Windows nicht auch gelöscht und neu erstellt wird, dieser Schritt aber halt einfach hinter GUI und/oder CLI "versteckt" ist?
Würde ich mal ausschließen, weil Du mit dem darunterliegenden NTFS dann Deine Daten weg sind, sobald Du eine Partiton löscht, was ja bei ext3/4 und LVM nicht der Fall ist. Da läuft IMHO ein schlichter extend. Das funktioniert ja auch nur mit der letzten Partition hinten an der Platte, wo dann die neuen freien Blöcke angehängt werden. Das ist ja dann wieder ein Vorteil, wenn man LVM verwendet, daß man dann jeder beliebigen Partition durch VolumeGroups oder LogicalVolumes entsprechend Platz aus dem neuen freien Bereich zuordnen kannst.
Du kannst unter Linux auch eines der GUI basierten Tools verwenden, damit kann die Partition ebenfalls aufgezogen werden ohne dass man diese vorher löschen muss.
Ich hab mir mal vor ca. 2-3 Jahren mal die Mühe gemacht, das mit verschiedenen Tools und VMs zu testen, mit sehr unterschiedlichen und ernüchternden Ergebnissen. Bei einem Tool ist mir sogar die VM komplett flöten gegangen. Gut, dank Snapshot-Sicherung im Xen kein Thema, trotzdem unschön. Der Weg über f/gdisk oder parted war bisher immer noch der "einfachste" und beste Weg.
Kannst auch via Hex-Editior in der MBR PartitionTable rumfummeln und den Endsektor umstellen - ohne vorher was zu löschen.
Ja, kann man, mache ich auch ungern, besonders beim Kunden, wenn der nicht mal ne Sicherung hat.
fdisk ist halt nunmal asbach-uralt und featuremässig seit Jahrzenten nicht mehr wirklich erweitert worden. Daher verwundert es mich nicht dass ein direktes aufziehen einer Partition nicht unterstützt wird, vor allem wenn man das selbe mit ganz wenig mehr Aufwand via löschen und neu erstellen auch erreichen kann.
Na ja, fdisk macht an sich auch nichts anderes, was Windows mit diskpart und Co tut: Partitionsinformationen in die MBR/GPT einbauen. Wenn ich neue Platten im Zugriff habe, verwende ich heute nur noch GPT, weil es schlichtweg moderner ist, und die Beschränkung von max. 4 primären Partitionen aufhebt. Schlauerweise macht man aber heute eh weniger Partitionen direkt auf der Platte, sondern regelt das über LVM, da flexibler.
Ich hatte gestern übrigens eine fast hitzige Diskussion, ob man direkt verfügbare Platten in dedizierten Servern, wie z.b. SSDs und HDDs (also keine virtuellen Platten über einem VM), noch Partitionieren soll oder nicht. Per LVM, xfs usw. kann man ja direkt auf das Device ohne Partition schreiben, z.B. mkfs.xfs /dev/sdb oder vgcreate /dev/sdc. Jedoch meinte mein Kollege berechtigt, daß dann hier keinerlei Anhaltspunkte für ein potentielles Recovery aus einem Volume möglich sei, und es nach wie vor besser ist, zu Partitionieren.
Update: Ich hab endlich wieder dieses Seite gefunden, wo es sehr gut dokumentiert wurde. Es entspricht fast dem, was ein Gast oben schon gepostet hatte, aber es geht hier auch wieder nur mit fdisk und Partition zerstören.
http://theducks.org/2009/11/expanding-lvm-partitions-in-vmware-on-the-fly/
Lokadamus
2016-05-15, 10:11:49
Kennt jemand das Tool system-config-lvm? Es setzt, so weit ich es verstehe, einen laufenden X- Server vorraus. ;(
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-system-config-lvm.html
Bin bei diesem Beitrag drüber gestolpert.
http://askubuntu.com/questions/196125/how-can-i-resize-an-lvm-partition-i-e-physical-volume
Pauschale Übersicht über ein paar FS, ob und wie sie vergrößern können.
https://wiki.ubuntuusers.de/Dateisystemgr%C3%B6%C3%9Fe_%C3%A4ndern/
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.