Guide pratique de LVM

Voici les instructions pour démarrer rapidement :)

Non. Il faut le mappeur de périphériques (device-mapper). Les utilitaires de LVM 2 l'utilisent pour s'interfacer avec le noyau et effectuer tout le mappage des interfaces (d'où le nom de mappeur de périphériques). A partir du moment où le mappeur de périphériques est disponible, vous devriez pouvoir utiliser LVM 2.

La cause première de ce problème est de ne pas avoir lancé la commande « dmsetup mknodes » après le redémarrage avec un noyau utilisant le mappeur de périphériques. Ce script génère le nœud de contrôle pour le mappeur de périphériques.

Si la commande « dmsetup mknodes » n'est pas disponible, ne désespérez pas! (Cependant cela veut probablement dire que vous devriez migrer vers la dernière version de device-mapper.) Il est assez simple de créer le fichier /dev/mapper/control par vous même :

Si vous utilisez le correctif de l'archive lvm2 pour les noyaux stables 2.4, toutes les fonctionnalités majeures de LVM1 seront compatibles avec les outils de LVM2 (il est toujours nécessaire de supprimer les instantanés avant la mise à jour de LVM 1 vers LVM 2.)

Si vous utilisez la version du mappeur de périphériques du noyau 2.6 de kernel.org, les commandes et types de LV suivants ne sont pas compatibles :

Oui. LVM 2 utilise le format de méta-données lvm 2. Ce format est beaucoup plus flexible que celui de LVM 1. Il supprime ou réduit la plupart des limitations de LVM 1.

Oui. LVM 2 est capable d'activer et de fonctionner avec les VG et LV créés avec LVM 1 à l'exception des instantanés qui doivent être supprimés avant la mise à jour. Les instantanés qui restent après la mise à jour devront être supprimés afin que l'on puisse activer leur volume d'origine avec LVM 2.

Oui. vgconvert permet de convertir un VG et tous les LV qu'il contient au nouveau format de méta-données lvm 2. Attention, il n'est pas toujours possible de revenir ensuite aux méta-données lvm 1.

Une des causes possibles de cela est le non positionnement par certaines versions de LVM 1 du champ UUID dans les structures de PV et VG alors qu'elles étaient supposées le faire. (L'utilisateur qui a signalé l'anomalie utilisait une Mandrake 9.2, mais d'autres distributions peuvent être impactées.) Les dernières versions des utilitaires de LVM 2 positionnent les UUID automatiquement s'ils manquent, il vous suffit donc de récupérer une version plus récente que la vôtre et le problème devrait être résolu. Dans le cas contraire, envoyez un message sur la liste de diffusion linux-lvm.

Passer à LVM 2 avec sa partition racine en LVM est un peu compliqué, mais pas impossible. Vous devez créer un noyau compatible avec le mappeur de périphériques et installer les utilitaires LVM 2. (Vous devriez faire une sauvegarde des utilitaires de LVM 1 ou trouver un disque de secours avec les utilitaires LVM au cas où vous en auriez besoin avant la fin de la migration.) Ensuite, vous devez trouver un script mkinitrd compatible avec votre distribution et de LVM 2.

Voici la liste des scripts mkinitrd que je connais et qui sont compatibles avec LVM 2, classés par distributions :

Très bien : LVM identifie les PV par leur UUID et non par le nom du périphérique.

Chaque disque (PV) possède un UUID, qui est un identifiant unique dans le système. Il est utilisé par « vgscan » pour le reconnaître lorsqu'un nouveau disque est ajouté et change la numérotation du disque. Pour cela, la plupart des distributions lancent vgscan dans les scripts de démarrage pour détecter les ajouts de matériel. Si vous faites des ajouts à chaud, je pense que vous devrez faire cela manuellement. D'un autre coté, si votre VG est activé et utilisé, la renumérotation ne devrait pas l'affecter du tout. L'identifiant est uniquement utilisé lors de l'activation et le pire qu'il puisse arriver sans le vgscan est que l'activation échoue avec un message indiquant qu'il manque un PV.

	Note
	Des problèmes de fonctionnement ou l'enlèvement d'un disque en cours d'utilisation par LVM cause des problèmes avec l'utilisation en cours et les futures activations du VG concerné.

Le chiffre 1,87 Go est arrondi à deux décimales, donc il correspond à quelque chose comme 1,866 Go. C'est juste une présentation à l'écran du chiffre pour donner une idée générale de la taille du VG. Si vous voulez donner une taille exacte, vous devez utiliser les extents à la place de quelque multiple d'octets.

Dans le cas de vgdisplay, utilisez le chiffre donné par Free PE à la place.

Free  PE / Size          478 / 1.87 GB
                         ^^^

Vous devriez donc lancer la commande suivante :

# lvcreate vg -l478

Remarquez qu'à la place d'un « L » majuscule, il faut utiliser un « l » minuscule pour dire à LVM d'utiliser les extents plutôt que les octets.

Dans le cas de vgs, il est nécessaire de lui demander explicitement le nombre d'extents disponibles :

# vgs -o +vg_free_count,vg_extent_count

Cela demande à vgs de rajouter le nombre d'extents libres et leur nombre total à la fin de la liste produite par vgs. Utilisez le nombre d'extents libres de la même façon que pour le cas de vgdisplay.

Avec LVM 2, les instantanés sont en lecture/écriture par défaut, alors qu'ils sont en lecture seule avec LVM 1. Voir Section 8, « Les instantanés (snapshots) » pour plus de détails.

Cela dépend de l'architecture CPU et du noyau utilisé :

Quand les gens commenceront à envoyer des entrées de FAQ ;)