LVM a-t-il besoin d'une table de partition?

18

Il semble que je suis capable de réussir un pvcreate au-dessus d'un périphérique de bloc brut, sans jamais prendre la décision de créer une table de partition. Je suis alors en mesure de créer un groupe de volumes, un volume logique et enfin un système de fichiers, de le monter et de tester via dd.

Cela semble fonctionner, mais j'ai besoin d'un contrôle de santé mentale. Est-ce une mauvaise idée?

Comment créer une table de partition GPT ou MBR au-dessus d'un périphérique de bloc brut?

Comment utiliser parted pour montrer quel type de table de partition est utilisé? J'ai essayé de faire:

séparé, sélectionnez / dev / sdb, imprimez et j'obtiens:

Erreur: / dev / sdb: étiquette de disque non reconnue

Pourtant, le lecteur est actuellement utilisé et je peux y lire et écrire. Est-ce la sortie attendue lors de l'exécution de LVM sur un périphérique de bloc brut sans table de partition? Des pensées?

Merci!

pantalon de chat
la source

Réponses:

29

Même si LVM lui-même ne se soucie pas d'avoir une vraie partition, une raison de la créer est de toute façon d'informer les programmes de partitionnement qu'il y a «quelque chose là-dedans». Un scénario de cauchemar est un nouvel administrateur système diagnostiquant un problème de démarrage sur un serveur, exécutant un programme de partitionnement, voyant des disques non partitionnés et concluant que le lecteur est corrompu.

Je ne vois aucun inconvénient à créer une partition LVM. Le faites vous?

Philippe
la source
1
+1 pour le scénario. Trop probable dans la vraie vie.
Hennes
1
+1 pour avoir été perspicace.
Alexander Janssen
Merci pour la réponse! Je ne vois certainement aucun inconvénient à avoir une table de partition. Je voulais juste confirmer avec un contrôle de santé mentale. Donc, l'ordre correct des couches est: périphérique de bloc, table de partition, groupe de volumes, volume logique, système de fichiers, est-ce correct?
pantalon de chat
8
L'inconvénient: si vous développez le périphérique de bloc et que vous n'avez pas utilisé de table de partition, vous pouvez immédiatement augmenter le volume physique avec pvresize. Si vous avez utilisé une table de partition, vous devez d'abord supprimer la partition et la recréer avec la plus grande taille.
sciurus
1
Faire preuve de prudence est une bonne chose, mais repousser la question ne constitue pas une excellente réponse. Il n'y a pas besoin de cette partition, et il y a des inconvénients à avoir une partition.
bryn
16

Bien que vous puissiez simplement créer un pv à partir d'un périphérique de bloc brut, j'essaye normalement de l'éviter car cela peut entraîner une confusion quant à l'utilisation du périphérique de bloc. Il peut également casser certaines des routines de découverte automatique que LVM peut utiliser s'il manque ses fichiers de configuration.

Voici un exemple d'utilisation de parted pour créer un GPT avec 1 partition qui est le lecteur entier et définir l'indicateur de partition sur lvm. Le mkpart nécessite que vous spécifiez un système de fichiers mais il ne crée pas le système de fichiers. Semble être un bug de longue date en partie. De plus, le décalage de départ de 1 M est destiné à garantir un alignement correct.

parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on
3dinfluence
la source
3
"Le mkpart nécessite que vous spécifiez un système de fichiers mais il ne crée pas le système de fichiers." Merci d'avoir mentionné cela, c'est ÉNORME pour établir la raison! :)
pantalon de chat
1
Ce n'est plus vrai. mkpart primary 1M 100%fonctionne et laisse le champ Système de fichiers vide.
Stark
1
@ 3dinfluence lvm fait maintenant l'alignement automatiquement, après de nombreuses années, je ne vois pas le vrai cas d'utilisation pour utiliser une partition pour le disque de données dédié pour lvm
c4f4t0r
5

Si vous créez un PV directement sur un périphérique de stockage virtuel à l'intérieur d'un invité KVM, vous remarquerez que les volumes logiques de l'invité sont visibles sur l'hyperviseur. Cela peut rendre les choses assez confuses si vous utilisez le même volume logique et les mêmes noms de groupe de volumes sur plusieurs invités. Vous pouvez également recevoir des avertissements sur l'hyperviseur indiquant qu'il ne trouve pas de périphérique.

Par exemple, j'ai recréé ce problème sur mon hyperviseur de test:

[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

Ici, vous pouvez voir 2 groupes de volumes avec le même nom, tous deux d'invités qui ne devraient pas vraiment apparaître sur l'hyperviseur.

Pour cette raison, je vous conseille d'utiliser d'abord parted ou fdisk pour y créer une partition KVM (comme indiqué dans la réponse précédente de 3dinfluence), avant de créer un PV et de l'ajouter à un groupe de volumes. De cette façon, les volumes logiques invités restent cachés de l'hyperviseur.

Paul Maunders
la source
1
Cela peut être évité si vous utilisez filterdans /etc/lvm/lvm.conf pour filtrer tous les périphériques de bloc utilisés directement par vos machines virtuelles.
Mircea Vutcovici
De toute façon, les disques sont toujours présents sur l'hôte - les partitions ne sont tout simplement pas mappées. kpartx -aferait cela pour vous. L'hyperviseur a accès à tous les disques invités, mais les groupes de volumes ne doivent pas être activés.
bryn
4

Un inconvénient est qu'il n'est pas possible d'ajouter de l'espace à chaud à un PV à l'intérieur d'une table de partition. Ce n'est pas un problème si vous utilisez l'ensemble du périphérique de bloc pour la PV.

user217432
la source
À partir de 2018, vous pouvez ajouter de l'espace sur un PV à l'intérieur d'une table de partition. J'ai créé ce script qui peut générer les commandes requises pour le faire: github.com/mircea-vutcovici/scripts/blob/master/vol_resize.sh
Mircea Vutcovici
3

Même si dans le passé j'utilisais une étiquette de disque MS-DOS ou une étiquette de disque GPT pour PV, je préfère maintenant utiliser directement LVM sur le périphérique de bloc principal. Il n'y a aucune raison d'utiliser 2 labels de disque, sauf si vous avez un cas d'utilisation très spécifique (comme un disque avec secteur de démarrage et partition de démarrage).

Les avantages d'avoir LVM directement sont:

  • simplicité - vous n'avez pas besoin d'utiliser 2 ensembles d'outils
  • flexibilité - vous pouvez utiliser pvmove pour déplacer les données d'un volume de disque à un autre sans interruption, vous pouvez utiliser un instantané et un provisionnement fin
  • vous n'avez pas besoin d'exécuter partprobe ou kpartx pour indiquer au noyau que vous avez créé / redimensionné / supprimé un volume. Et partprobe / kpartx peut échouer si des partitions sont en cours d'utilisation et vous devrez peut-être redémarrer
  • peut-être de meilleures performances, par rapport à l'utilisation de LVM sur des tables de disques MS-DOS ou GPT
Mircea Vutcovici
la source
2
Je ne sais pas pourquoi tout le monde veut cette partition - mais répondez ici dans le sens de "pourquoi pas". Cette réponse est meilleure - vous n'avez pas besoin d'une partition si vous allez utiliser tout le disque. Avoir une partition peut également rendre le redimensionnement / extension des disques beaucoup plus pénible.
bryn
de nombreux administrateurs système Unix apportent cette logique à linux, je me souviens du gestionnaire de volumes veritas qui fonctionne avec le public et le privé, sous Linux, cela n'a aucun sens
c4f4t0r