Benötigt LVM eine Partitionstabelle?

Es scheint, dass ich in der Lage bin, ein pvcreate auf einem Raw-Block-Gerät erfolgreich durchzuführen, ohne jemals eine Partitionstabelle zu erstellen. Ich bin dann in der Lage, eine Datenträgergruppe, einen logischen Datenträger und schließlich ein Dateisystem zu erstellen, es bereitzustellen und über dd zu testen.

Es scheint zu funktionieren, aber ich brauche eine Überprüfung der geistigen Gesundheit. Ist das eine schlechte Idee?

Wie erstelle ich eine GPT- oder MBR-Partitionstabelle auf einem Raw-Block-Gerät?

Wie kann ich mit parted anzeigen, welche Art von Partitionstabelle verwendet wird? Ich habe versucht zu tun:

getrennt, wähle / dev / sdb, drucke und ich bekomme:

Fehler: / dev / sdb: Unbekannte Festplattenbezeichnung

Das Laufwerk wird derzeit verwendet und ich kann es lesen und beschreiben. Ist das die erwartete Ausgabe, wenn LVM auf einem Raw-Block-Gerät ohne Partitionstabelle ausgeführt wird? Irgendwelche Gedanken?

Vielen Dank!

Auch wenn es LVM selbst nicht wichtig ist, eine echte Partition zu haben, besteht ein Grund, diese zu erstellen, darin, Partitionierungsprogrammen mitzuteilen, dass "etwas da ist". Ein Alptraumszenario ist ein neuer Systemadministrator, der ein Startproblem auf einem Server diagnostiziert, ein Partitionierungsprogramm startet, nicht partitionierte Datenträger erkennt und feststellt, dass das Laufwerk beschädigt ist.

Ich sehe keinen Nachteil beim Erstellen einer LVM-Partition. Machst du?

Sie können zwar nur einen pv aus einem unformatierten Blockgerät erstellen, aber ich versuche normalerweise, dies zu vermeiden, da dies zu Unklarheiten darüber führen kann, wofür das Blockgerät verwendet wird. Es kann auch dazu führen, dass einige der Routinen für die automatische Erkennung, die LVM verwenden kann, beschädigt werden, wenn die Konfigurationsdateien fehlen.

Hier ist ein Beispiel für die Verwendung von parted zum Erstellen einer GPT mit 1 Partition, die das gesamte Laufwerk darstellt, und setzen Sie das Partitionsflag auf lvm. Für mkpart muss ein Dateisystem angegeben werden, das Dateisystem wird jedoch nicht erstellt. Scheint ein langjähriger Fehler zu sein. Der Startversatz von 1M soll auch sicherstellen, dass Sie die richtige Ausrichtung erhalten.

parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on

Wenn Sie eine PV direkt auf einem virtuellen Speichergerät in einem KVM-Gast erstellen, werden Sie feststellen, dass die logischen Volumes des Gasts auf dem Hypervisor sichtbar sind. Dies kann zu Verwirrung führen, wenn Sie für mehrere Gäste denselben logischen Datenträger und dieselben Datenträgergruppennamen verwenden. Möglicherweise erhalten Sie auch Warnungen, dass der Hypervisor kein Gerät finden kann.

Beispielsweise habe ich dieses Problem auf meinem Testhypervisor neu erstellt:

[root@testhost ~]# vgs
  Couldn't find device with uuid dCaylp-1kvL-syiF-A2bW-NTPP-Ehlb-gtfxZz.
  VG          #PV #LV #SN Attr   VSize   VFree  
  vg_main       2   2   0 wz-pn-  19.25g 768.00m
  vg_main       2   2   0 wz-pn-  19.25g 768.00m
  vg_testhost   1   8   0 wz--n- 237.98g 120.15g

Hier sehen Sie 2 gleichnamige Volume-Gruppen, beide von Gästen, die eigentlich nicht auf dem Hypervisor erscheinen sollten.

Aus diesem Grund würde ich empfehlen, dass Sie zunächst eine KVM-Partition mit parted oder fdisk erstellen (wie in der vorherigen Antwort von 3dinfluence gezeigt), bevor Sie eine PV erstellen und einer Volumengruppe hinzufügen. Auf diese Weise bleiben die logischen Gastvolumes vor dem Hypervisor verborgen.

Ein Nachteil ist, dass es nicht möglich ist, einem PV innerhalb einer Partitionstabelle Speicherplatz im laufenden Betrieb hinzuzufügen. Dies ist kein Problem, wenn Sie das gesamte Blockgerät für die PV verwenden.

Laut LVM-Leitfaden von RedHat, Abschnitt 4.2.1 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/physvol_admin

Sie sagten, es sei nicht erforderlich, die Partitionstabelle zu haben, und sie schlugen uns sogar vor, sie zu zerstören, wenn wir die gesamte Festplatte für VG (Volume Group) verwenden, es sei denn, wir beabsichtigen, nur Teile davon (Partition) einzuschließen.

Auch wenn ich in der Vergangenheit MS-DOS-Disklabel oder GPT-Disklabel für PV verwendet habe, bevorzuge ich jetzt die direkte Verwendung von LVM auf dem Hauptblockgerät. Es gibt keinen Grund, 2 Disklabels zu verwenden, es sei denn, Sie haben einen ganz bestimmten Anwendungsfall (wie eine Festplatte mit Bootsektor und Bootpartition).

Die Vorteile von LVM direkt sind:

• Einfachheit - Sie müssen nicht zwei Werkzeugsätze verwenden
• Flexibilität - Sie können pvmove verwenden, um die Daten ohne Ausfallzeit von einem Datenträger auf einen anderen zu verschieben. Sie können Snapshot und Thin Provisioning verwenden
• Sie müssen weder partprobe noch kpartx ausführen, um dem Kernel mitzuteilen, dass Sie ein Volume erstellt, seine Größe geändert oder es gelöscht haben. Und partprobe / kpartx kann fehlschlagen, wenn Partitionen verwendet werden und möglicherweise ein Neustart erforderlich ist
• Möglicherweise bessere Leistung im Vergleich zur Verwendung von LVM über MS-DOS- oder GPT-Disklables