Gestion des disques avec LVM2 sous Linux
Sources :
- http://ditwww.epfl.ch/SIC/SA/SPIP/Publications/spip.php?article816
- http://www.wearegeeks.info/Utilisation-de-LVM
A priori, pour gérer efficacement les partitions sous linux, il faut installer lvm2. Lors de l'installation de Ubuntu server, c'est proposé. L'expérience se faisant, le lvm2 est surtout intéressant, si le système est monté sur une machine physique.
En effet, dans une machine virtuelle, nous aurons plus intérêt à installer le système sur une partition standard en ext3, sur un disque virtuel bien dimensionné au départ. Puis nous ajouterons autant de disques virtuels pour la partie data, que nous monterons à la racine d'un répertoire /var/data1 /var/data2 .... par exemple.
Trois raisons au moins pour privilégié cette technique à l'installation de lvm2 sur un disque virtuel :
- un disque virtuel s'ajoute et se supprime très aisément sans arrêter le système,
- face à lvm2, il y a beaucoup moins de choses à assimiler,
- le principe s'adapte autant pour une machine linux que pour une machine windows.
Bon, mais le concepte de lvm2 est intéressant et c'est pourquoi je me suis fait ce petit mémo.
Pour "jouer" avec Lvm2, quoi de plus pratique que de s'y frotter au sein d'une machine virtuelle ! C'est dans ce contexte que j''ai installé un Ubuntu server avec l'installation de lvm2 et un formatage ext3.
Grâce à l'environnement VMware, j'ai aggrandi l'image disque Ubuntu.vmdk. Et maintenant, tout l'exercice se situe dans l'espace libre ainsi créé.
La situation lvm2 créée par l'installation de Ubuntu :
vgdisplay (Volume Group)
VG Name Ubuntu
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 1,76 GB (correspond à ce qu'indique df)
PE Size 4,00 MB
Total PE 450
Alloc PE / Size 450 / 1,76 GB
Free PE / Size 0 / 0
VG UUID NNTX7T-Q5W3-sJBn-M1HL-Uv5n-WFBS-H6F1XN
Le groupe est un moyen d'associer :
- d'une part des partitions physiques (de vrai partitions sur de vrai disques physiques (même s'ils sont virtuels sous VMware !)
- d'autre part des partitions logiques (des partitions virtuelles qui seront vues comme de vrai partitions par le système linux.
Dans ce groupe, nous constatons qu'il y a un disque/partition physique :
Cur PV 1
Act PV 1
Et il y a deux partitions virtuelles :
Cur LV 2
Open LV 2
Nous regardons le détail concernant PV (Physical Volume - disque/partition physique)
pvdisplay
PV Name /dev/sda6
VG Name Ubuntu
PV Size 1,76 GB / not usable 0
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 450
Free PE 0
Allocated PE 450
PV UUID Qm5BkB-HHbS-DjV3-xHQr-Gth9-LO1N-jV736v
Nous constatons que la partition /dev/sda6 est bien rattachée au groupe "Ubuntu" :
PV Name /dev/sda6
VG Name Ubuntu
Nous regardons le détail concernant LV (Logical Volume - partition logique)
lvdisplay
--- Logical volume ---
LV Name /dev/Ubuntu/root
VG Name Ubuntu
LV UUID 5WCMha-fRQY-vvpb-GLsa-PSnu-CN14-T33lQO
LV Write Access read/write
LV Status available
# open 1
LV Size 1,65 GB
Current LE 422
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:0
--- Logical volume ---
LV Name /dev/Ubuntu/swap_1
VG Name Ubuntu
LV UUID x2smzQ-zXia-ap3N-oxKX-SiwA-hVd2-DwUv6l
LV Write Access read/write
LV Status available
# open 2
LV Size 112,00 MB
Current LE 28
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:1
Il y en a bien 2, rattachées au groupe "Ubuntu"
- L'une est la partition principale sur laquelle est installée le système Ubuntu
LV Name /dev/Ubuntu/root
VG Name Ubuntu
- L'autre est la partition de swapping
LV Name /dev/Ubuntu/swap_1
VG Name Ubuntu
La situation sous le système Linux Ubuntu :
Les partitions physiques installées sur notre disque virtuel :
fdisk -l (Liste des partitions)
Device Boot Start End Blocks Id System
/dev/sda1 1 261 2096451 5 Extended
/dev/sda5 * 1 31 248944+ 83 Linux
/dev/sda6 32 261 1847443+ 8e Linux LVM
Si nous regardons la table des volumes mountés avec more /etc/mtab, nous voyons :
/dev/mapper/Ubuntu-root / ext3 rw,errors=remount-ro 0 0
/dev/sda5 /boot ext3 rw 0 0
Donc c'est bien la partition logique LVM "Ubuntu-root" qui est montée et non /dev/sda6 (si celle-ci avait été aussi une partition linux ext3 (id 83) au lieu d'une partition Linux LVM (id 8E)). La seconde partition virtuelle du groupe "Ubuntu" n'est naturellement pas montée puisqu'elle sert pour le swapping.
Par contre, rien ne dit pour l'instant que /dev/mapper/Ubuntu-root, correspond à la première LV /dev/Ubuntu/root. La réponse se trouve ici, sous /etc, dans le répertoire automatiquement créé par lvm et qui porte le nom du groupe "Ubuntu" :
/dev/Ubuntu# ls -l
lrwxrwxrwx 1 root root 23 2007-10-18 11:03 root -> /dev/mapper/Ubuntu-root
lrwxrwxrwx 1 root root 25 2007-10-18 11:03 swap_1 -> /dev/mapper/Ubuntu-swap_1
Lvm gère aussi le répertoire /dev/mapper qui contient l'ensemble des partitions virtuelles tous groupes confondus.
Occupation de l'espace libre obtenu par l'aggrandissement du disque virtuel VMware :
Pour gérer les partitions physiques nous utiliserons :
- cfdisk (plus intuitif que sfdisk et parted) pour créer les partitions sur le disque /dev/sda
- penser simplement à terminer les actions dans cfdisk par un "w(rite)"
- il y aurait aussi les outils de partitionnement en mode graphique gparted et qparted (non testés)
- mke2fs -j pour formater en ext3 (ext2 journalisé)
1ère solution - nous nous passons de lvm, mais c'est dommage dans le cas d'aggrandissement futurs.
- avec cfdisk - création d'une nouvelle partition linux (id 83) dans l'espace "free" qui prendra le nom /dev/sda7
- mke2fs -j /dev/sda7 - formatage en ext3
- nous inscrivons /dev/sda7 dans /etc/fstab avec une ligne supplémentaire du type :
/dev/sda7 /var-data ext3 defaults 0 2
- mount /etc/sda7 - montage du volume /etc/sda7
2ème solution - nous utilison lvm
- avec cfdisk - création d'une nouvelle partition linux lvm (id 8E) dans l'espace "free" qui prendra le nom /dev/sda7
Intégration d'une nouvelle partition physique sous Lvm :
Dans le cas de la 2ème solution ci-dessous, nous avons créé une seconde partition physique Lvm que nous allons intégrée dans le groupe "Ubuntu" et voir ensuite ce que l'on en fait....
Nous regardons la situation physique sur notre disque virtuel VMware :
sfdisk -l
Device Boot Start End #cyls #blocks Id System
/dev/sda1 0+ 390 391- 3140676 5 Extended
/dev/sda5 * 0+ 30 31- 248944+ 83 Linux
/dev/sda6 31+ 260 230- 1847443+ 8e Linux LVM
/dev/sda7 261+ 390 130- 1044193+ 8e Linux LVM
Nous déclarons /dev/sda7 dans l'espace Lvm du système :
pvcreate /dev/sda7
-> Physical volume "/dev/sda7" successfully created
Nous intégrons le nouveau PV /dev/sda7 dans le groupe "Ubuntu"
vgextend Ubuntu /dev/sda7
-> Volume group "Ubuntu" successfully extended
Nous regardons la place maintenant disponible dans le groupe "Ubuntu"
vgdisplay
--- Volume group ---
VG Name Ubuntu
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 2
Act PV 2
VG Size 2,75 GB
PE Size 4,00 MB
Total PE 704
Alloc PE / Size 450 / 1,76 GB
Free PE / Size 254 / 1016,00 MB
VG UUID NNTX7T-Q5W3-sJBn-M1HL-Uv5n-WFBS-H6F1XN
Nous avons 1016 Mo de disponibles :
Ensuite 2 choix (c'est là tout l'intéret de Lvm) :
- 1) soit nous créons une autre partition virtuelle LV
- 2) soit nous aggrandissons la LV existante /dev/Ubuntu/root,
1 - Cas création d'une nouvelle partition Logique "data" sous Lvm :
lvcreate -L1016M -n data Ubuntu
-> Logical volume "data" created
- mke2fs -j /dev/Ubuntu/data - formatage en ext3
- nous inscrivons /dev/Ubuntu/data dans /etc/fstab avec une ligne supplémentaire du type :
/dev/Ubuntu/data /var-data ext3 defaults 0 2
- mkdir /var-data - création du point de montage
- mount /etc/Ubuntu/data - montage du volume /dev/Ubuntu/data
nous aurions tout aussi bien pu inscrire /dev/mapper/Ubuntu-data dans /etc/fstab
/dev/mapper/Ubuntu-data /var-data ext3 defaults 0 2
- mkdir /var-data - création du point de montage
- mount /etc/mapper/Ubuntu-data - montage du volume /dev/Ubuntu/data
2 : signifie que le système de donnée sera vérifié par fsck, mais après le système racine qui comporte le n°1
2 - Cas extension de la partition Logique existante "root" sous Lvm :
lvextend -L+1016M /dev/Ubuntu/root
-> Extending logical volume root to 2,64 GB
-> Logical volume root successfully resized
Si notre filesystème était en ReiserFS, nous pourrions alors étendre le système de fichier à chaud,
Mais comme nous sommes sous Ext3, il faut maintenant rebooter sous un autre volume linux (CD, Usb), et faire les opérations suivantes (non testé) :
- e2fsck -fy /dev/Ubuntu/root
- resize2fs /dev/Ubuntu/root
- e2fsck -fy /dev/Ubuntu/root
Jouons avec Lvm :
- D'abord j'invite à vérifier régulièrement avec vgdisplay, pvdisplay, lvdisplay, les effets de nos manipulations diverses.
- scénario 1 : j'ai étendu /dev/Ubuntu/root, je n'ai pas touché au filesystem et je reviens à la situation antérieure :
lvreduce -L-1016M /dev/Ubuntu/root (exactement identique au lvextend)
-> WARNING: Reducing active and open logical volume to 1,65 GB
-> THIS MAY DESTROY YOUR DATA (filesystem etc.)
-> Do you really want to reduce root? [y/n]: y (je n'ai pas touché au filesystem)
-> Reducing logical volume root to 1,65 GB
-> Logical volume root successfully resized
- scénario 2 : Tout ce qui "data" doit être dans un groupe "DataGroupe"
vgreduce Ubuntu /dev/sda7
-> Removed "/dev/sda7" from volume group "Ubuntu"
vgcreate DataGroupe /dev/sda7
-> Volume group "DataGroupe" successfully created
lvcreate -L1016M -n data DataGroupe
-> Logical volume "data" created
mke2fs -j /dev/DataGroupe/data (Création d'un filesystem ext3 sur /dev/DataGroupe/data)
- scénario 3 : Erreur ! finalement, tout ce qui est "data" peut retourner dans le groupe "Ubuntu"
umount /dev/DataGroupe/data
lvremove DataGroupe/data
-> Logical volume "data" successfully removed
lvcreate -L1016M -n data Ubuntu
... mais j'ai perdu le système de fichier, les données dans ce déplacement, donc nous préférerons le scénario 4
- scénario 4 : Erreur ! finalement, tout ce qui est "data" peut retourner dans le groupe "Ubuntu"
umount /dev/DataGroupe/data
vgchange -a n DataGroupe (available "no") - Nous mettons tout le groupe DataGroupe en "Indisponible"
-> 0 logical volume(s) in volume group "Data" now active
vgmerge -t Ubuntu DataGroupe (-t pour test ... ensuite on l'enlève).
vgmerge Ubuntu DataGroupe
-> Volume group "DataGroupe" successfully merged into "Ubuntu"
lvchange -a y Ubuntu/data (available "yes") - Nous rendons la LV "disponible"
mount /dev/Ubuntu/data
Nous constatons aussi que le répertoire /dev/DataGroupe/data à bien disparu au profit de /dev/Ubuntu/data
Listes des commandes GV, PV, LV :
- Groupes de Volumes :
vgcfgbackup : sauvegarder la VGDA.
vgcfgrestore : restaurer la VGDA.
vgchange : changer les attributs d’un VG.
vgck : vérification de la VGDA.
vgcreate : créer un VG.
vgdisplay : voir les informations.
vgexport : désactiver un VG pour pouvoir extraire les PV.
vgimport : activer et déclarer un VG sur le système.
vgextend : ajouter un ou plusieurs PV dans un VG.
vgmerge : fusionner deux VG.
vgmknodes : recréer /dev/nom_volume et le fichier spécial group.
vgreduce : extraire un ou plusieurs PV d’un VG.
vgremove : supprimer un VG.
vgrename : renommer un VG.
Volumes physiques :
pvchange : changer les attributs d’un PV.
pvcreate : création d’un PV.
pvdata : afficher des informations de debug.
pvdisplay : afficher des informations d’un PV.
pvscan : lister tous les PV existant sur tous les disques.
Volumes logiques :
lvcreate : création d’un VL
lvchange : modification des attributs d’un VL.
lvdisplay : voir les informations d’un VL.
lvextend : augmenter la taille d’un VL.
lvreduce : réduire la taille d’un VL.
lvremove : supprimer un VL.
lvrename : renommer un VL.
lvscan : recherche de tous les VL existants.
Conclusion :
Les possibilités de Lvm sont nombreuses, et nous sommes loin d'avoir "joué" avec toutes les possibilités, notamment quand il s'agit de déplacer ou changer des disques physiques.
Maintenant, comme j'ai indiqué lors de l'introduction de ce mémo, avec la virtualisation du hardware (y compris les disques que l'on agrandi, réduit, déplace, copie, ajoute à volonté), Lvm installé sur une image disque semble inutile. Ca fait de la virtualisation dans la virtualisation... A utiliser donc sur des supports physico-physiques.
Dernière modification : 07/12/07
- http://ditwww.epfl.ch/SIC/SA/SPIP/Publications/spip.php?article816
- http://www.wearegeeks.info/Utilisation-de-LVM
A priori, pour gérer efficacement les partitions sous linux, il faut installer lvm2. Lors de l'installation de Ubuntu server, c'est proposé. L'expérience se faisant, le lvm2 est surtout intéressant, si le système est monté sur une machine physique.
En effet, dans une machine virtuelle, nous aurons plus intérêt à installer le système sur une partition standard en ext3, sur un disque virtuel bien dimensionné au départ. Puis nous ajouterons autant de disques virtuels pour la partie data, que nous monterons à la racine d'un répertoire /var/data1 /var/data2 .... par exemple.
Trois raisons au moins pour privilégié cette technique à l'installation de lvm2 sur un disque virtuel :
- un disque virtuel s'ajoute et se supprime très aisément sans arrêter le système,
- face à lvm2, il y a beaucoup moins de choses à assimiler,
- le principe s'adapte autant pour une machine linux que pour une machine windows.
Bon, mais le concepte de lvm2 est intéressant et c'est pourquoi je me suis fait ce petit mémo.
Pour "jouer" avec Lvm2, quoi de plus pratique que de s'y frotter au sein d'une machine virtuelle ! C'est dans ce contexte que j''ai installé un Ubuntu server avec l'installation de lvm2 et un formatage ext3.
Grâce à l'environnement VMware, j'ai aggrandi l'image disque Ubuntu.vmdk. Et maintenant, tout l'exercice se situe dans l'espace libre ainsi créé.
La situation lvm2 créée par l'installation de Ubuntu :
vgdisplay (Volume Group)
VG Name Ubuntu
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 1,76 GB (correspond à ce qu'indique df)
PE Size 4,00 MB
Total PE 450
Alloc PE / Size 450 / 1,76 GB
Free PE / Size 0 / 0
VG UUID NNTX7T-Q5W3-sJBn-M1HL-Uv5n-WFBS-H6F1XN
Le groupe est un moyen d'associer :
- d'une part des partitions physiques (de vrai partitions sur de vrai disques physiques (même s'ils sont virtuels sous VMware !)
- d'autre part des partitions logiques (des partitions virtuelles qui seront vues comme de vrai partitions par le système linux.
Dans ce groupe, nous constatons qu'il y a un disque/partition physique :
Cur PV 1
Act PV 1
Et il y a deux partitions virtuelles :
Cur LV 2
Open LV 2
Nous regardons le détail concernant PV (Physical Volume - disque/partition physique)
pvdisplay
PV Name /dev/sda6
VG Name Ubuntu
PV Size 1,76 GB / not usable 0
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 450
Free PE 0
Allocated PE 450
PV UUID Qm5BkB-HHbS-DjV3-xHQr-Gth9-LO1N-jV736v
Nous constatons que la partition /dev/sda6 est bien rattachée au groupe "Ubuntu" :
PV Name /dev/sda6
VG Name Ubuntu
Nous regardons le détail concernant LV (Logical Volume - partition logique)
lvdisplay
--- Logical volume ---
LV Name /dev/Ubuntu/root
VG Name Ubuntu
LV UUID 5WCMha-fRQY-vvpb-GLsa-PSnu-CN14-T33lQO
LV Write Access read/write
LV Status available
# open 1
LV Size 1,65 GB
Current LE 422
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:0
--- Logical volume ---
LV Name /dev/Ubuntu/swap_1
VG Name Ubuntu
LV UUID x2smzQ-zXia-ap3N-oxKX-SiwA-hVd2-DwUv6l
LV Write Access read/write
LV Status available
# open 2
LV Size 112,00 MB
Current LE 28
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:1
Il y en a bien 2, rattachées au groupe "Ubuntu"
- L'une est la partition principale sur laquelle est installée le système Ubuntu
LV Name /dev/Ubuntu/root
VG Name Ubuntu
- L'autre est la partition de swapping
LV Name /dev/Ubuntu/swap_1
VG Name Ubuntu
La situation sous le système Linux Ubuntu :
Les partitions physiques installées sur notre disque virtuel :
fdisk -l (Liste des partitions)
Device Boot Start End Blocks Id System
/dev/sda1 1 261 2096451 5 Extended
/dev/sda5 * 1 31 248944+ 83 Linux
/dev/sda6 32 261 1847443+ 8e Linux LVM
Si nous regardons la table des volumes mountés avec more /etc/mtab, nous voyons :
/dev/mapper/Ubuntu-root / ext3 rw,errors=remount-ro 0 0
/dev/sda5 /boot ext3 rw 0 0
Donc c'est bien la partition logique LVM "Ubuntu-root" qui est montée et non /dev/sda6 (si celle-ci avait été aussi une partition linux ext3 (id 83) au lieu d'une partition Linux LVM (id 8E)). La seconde partition virtuelle du groupe "Ubuntu" n'est naturellement pas montée puisqu'elle sert pour le swapping.
Par contre, rien ne dit pour l'instant que /dev/mapper/Ubuntu-root, correspond à la première LV /dev/Ubuntu/root. La réponse se trouve ici, sous /etc, dans le répertoire automatiquement créé par lvm et qui porte le nom du groupe "Ubuntu" :
/dev/Ubuntu# ls -l
lrwxrwxrwx 1 root root 23 2007-10-18 11:03 root -> /dev/mapper/Ubuntu-root
lrwxrwxrwx 1 root root 25 2007-10-18 11:03 swap_1 -> /dev/mapper/Ubuntu-swap_1
Lvm gère aussi le répertoire /dev/mapper qui contient l'ensemble des partitions virtuelles tous groupes confondus.
Occupation de l'espace libre obtenu par l'aggrandissement du disque virtuel VMware :
Pour gérer les partitions physiques nous utiliserons :
- cfdisk (plus intuitif que sfdisk et parted) pour créer les partitions sur le disque /dev/sda
- penser simplement à terminer les actions dans cfdisk par un "w(rite)"
- il y aurait aussi les outils de partitionnement en mode graphique gparted et qparted (non testés)
- mke2fs -j pour formater en ext3 (ext2 journalisé)
1ère solution - nous nous passons de lvm, mais c'est dommage dans le cas d'aggrandissement futurs.
- avec cfdisk - création d'une nouvelle partition linux (id 83) dans l'espace "free" qui prendra le nom /dev/sda7
- mke2fs -j /dev/sda7 - formatage en ext3
- nous inscrivons /dev/sda7 dans /etc/fstab avec une ligne supplémentaire du type :
/dev/sda7 /var-data ext3 defaults 0 2
- mount /etc/sda7 - montage du volume /etc/sda7
2ème solution - nous utilison lvm
- avec cfdisk - création d'une nouvelle partition linux lvm (id 8E) dans l'espace "free" qui prendra le nom /dev/sda7
Intégration d'une nouvelle partition physique sous Lvm :
Dans le cas de la 2ème solution ci-dessous, nous avons créé une seconde partition physique Lvm que nous allons intégrée dans le groupe "Ubuntu" et voir ensuite ce que l'on en fait....
Nous regardons la situation physique sur notre disque virtuel VMware :
sfdisk -l
Device Boot Start End #cyls #blocks Id System
/dev/sda1 0+ 390 391- 3140676 5 Extended
/dev/sda5 * 0+ 30 31- 248944+ 83 Linux
/dev/sda6 31+ 260 230- 1847443+ 8e Linux LVM
/dev/sda7 261+ 390 130- 1044193+ 8e Linux LVM
Nous déclarons /dev/sda7 dans l'espace Lvm du système :
pvcreate /dev/sda7
-> Physical volume "/dev/sda7" successfully created
Nous intégrons le nouveau PV /dev/sda7 dans le groupe "Ubuntu"
vgextend Ubuntu /dev/sda7
-> Volume group "Ubuntu" successfully extended
Nous regardons la place maintenant disponible dans le groupe "Ubuntu"
vgdisplay
--- Volume group ---
VG Name Ubuntu
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 2
Act PV 2
VG Size 2,75 GB
PE Size 4,00 MB
Total PE 704
Alloc PE / Size 450 / 1,76 GB
Free PE / Size 254 / 1016,00 MB
VG UUID NNTX7T-Q5W3-sJBn-M1HL-Uv5n-WFBS-H6F1XN
Nous avons 1016 Mo de disponibles :
Ensuite 2 choix (c'est là tout l'intéret de Lvm) :
- 1) soit nous créons une autre partition virtuelle LV
- 2) soit nous aggrandissons la LV existante /dev/Ubuntu/root,
1 - Cas création d'une nouvelle partition Logique "data" sous Lvm :
lvcreate -L1016M -n data Ubuntu
-> Logical volume "data" created
- mke2fs -j /dev/Ubuntu/data - formatage en ext3
- nous inscrivons /dev/Ubuntu/data dans /etc/fstab avec une ligne supplémentaire du type :
/dev/Ubuntu/data /var-data ext3 defaults 0 2
- mkdir /var-data - création du point de montage
- mount /etc/Ubuntu/data - montage du volume /dev/Ubuntu/data
nous aurions tout aussi bien pu inscrire /dev/mapper/Ubuntu-data dans /etc/fstab
/dev/mapper/Ubuntu-data /var-data ext3 defaults 0 2
- mkdir /var-data - création du point de montage
- mount /etc/mapper/Ubuntu-data - montage du volume /dev/Ubuntu/data
2 : signifie que le système de donnée sera vérifié par fsck, mais après le système racine qui comporte le n°1
2 - Cas extension de la partition Logique existante "root" sous Lvm :
lvextend -L+1016M /dev/Ubuntu/root
-> Extending logical volume root to 2,64 GB
-> Logical volume root successfully resized
Si notre filesystème était en ReiserFS, nous pourrions alors étendre le système de fichier à chaud,
Mais comme nous sommes sous Ext3, il faut maintenant rebooter sous un autre volume linux (CD, Usb), et faire les opérations suivantes (non testé) :
- e2fsck -fy /dev/Ubuntu/root
- resize2fs /dev/Ubuntu/root
- e2fsck -fy /dev/Ubuntu/root
Jouons avec Lvm :
- D'abord j'invite à vérifier régulièrement avec vgdisplay, pvdisplay, lvdisplay, les effets de nos manipulations diverses.
- scénario 1 : j'ai étendu /dev/Ubuntu/root, je n'ai pas touché au filesystem et je reviens à la situation antérieure :
lvreduce -L-1016M /dev/Ubuntu/root (exactement identique au lvextend)
-> WARNING: Reducing active and open logical volume to 1,65 GB
-> THIS MAY DESTROY YOUR DATA (filesystem etc.)
-> Do you really want to reduce root? [y/n]: y (je n'ai pas touché au filesystem)
-> Reducing logical volume root to 1,65 GB
-> Logical volume root successfully resized
- scénario 2 : Tout ce qui "data" doit être dans un groupe "DataGroupe"
vgreduce Ubuntu /dev/sda7
-> Removed "/dev/sda7" from volume group "Ubuntu"
vgcreate DataGroupe /dev/sda7
-> Volume group "DataGroupe" successfully created
lvcreate -L1016M -n data DataGroupe
-> Logical volume "data" created
mke2fs -j /dev/DataGroupe/data (Création d'un filesystem ext3 sur /dev/DataGroupe/data)
- scénario 3 : Erreur ! finalement, tout ce qui est "data" peut retourner dans le groupe "Ubuntu"
umount /dev/DataGroupe/data
lvremove DataGroupe/data
-> Logical volume "data" successfully removed
lvcreate -L1016M -n data Ubuntu
... mais j'ai perdu le système de fichier, les données dans ce déplacement, donc nous préférerons le scénario 4
- scénario 4 : Erreur ! finalement, tout ce qui est "data" peut retourner dans le groupe "Ubuntu"
umount /dev/DataGroupe/data
vgchange -a n DataGroupe (available "no") - Nous mettons tout le groupe DataGroupe en "Indisponible"
-> 0 logical volume(s) in volume group "Data" now active
vgmerge -t Ubuntu DataGroupe (-t pour test ... ensuite on l'enlève).
vgmerge Ubuntu DataGroupe
-> Volume group "DataGroupe" successfully merged into "Ubuntu"
lvchange -a y Ubuntu/data (available "yes") - Nous rendons la LV "disponible"
mount /dev/Ubuntu/data
Nous constatons aussi que le répertoire /dev/DataGroupe/data à bien disparu au profit de /dev/Ubuntu/data
Listes des commandes GV, PV, LV :
- Groupes de Volumes :
vgcfgbackup : sauvegarder la VGDA.
vgcfgrestore : restaurer la VGDA.
vgchange : changer les attributs d’un VG.
vgck : vérification de la VGDA.
vgcreate : créer un VG.
vgdisplay : voir les informations.
vgexport : désactiver un VG pour pouvoir extraire les PV.
vgimport : activer et déclarer un VG sur le système.
vgextend : ajouter un ou plusieurs PV dans un VG.
vgmerge : fusionner deux VG.
vgmknodes : recréer /dev/nom_volume et le fichier spécial group.
vgreduce : extraire un ou plusieurs PV d’un VG.
vgremove : supprimer un VG.
vgrename : renommer un VG.
Volumes physiques :
pvchange : changer les attributs d’un PV.
pvcreate : création d’un PV.
pvdata : afficher des informations de debug.
pvdisplay : afficher des informations d’un PV.
pvscan : lister tous les PV existant sur tous les disques.
Volumes logiques :
lvcreate : création d’un VL
lvchange : modification des attributs d’un VL.
lvdisplay : voir les informations d’un VL.
lvextend : augmenter la taille d’un VL.
lvreduce : réduire la taille d’un VL.
lvremove : supprimer un VL.
lvrename : renommer un VL.
lvscan : recherche de tous les VL existants.
Conclusion :
Les possibilités de Lvm sont nombreuses, et nous sommes loin d'avoir "joué" avec toutes les possibilités, notamment quand il s'agit de déplacer ou changer des disques physiques.
Maintenant, comme j'ai indiqué lors de l'introduction de ce mémo, avec la virtualisation du hardware (y compris les disques que l'on agrandi, réduit, déplace, copie, ajoute à volonté), Lvm installé sur une image disque semble inutile. Ca fait de la virtualisation dans la virtualisation... A utiliser donc sur des supports physico-physiques.
Dernière modification : 07/12/07