informatique:nix:linux:linux_lvm

LVM : commandes de base

Recherche les PVs sur tous les disques.

root@SpaceServer:/tmp> pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/cciss/c0d0p2" of VG "rootvg" [67.32 GB / 49.32 GB free]
pvscan -- total: 1 [67.33 GB] / in use: 1 [67.33 GB] / in no VG: 0 [0]

Initialise le disque pour pouvoir être utilisé avec LVM. Si un PV existe déjà on peut utiliser -ff mais dans ce cas il faut être certain de ne pas écraser un disque utilisé ailleurs.

root@SpaceServer:/tmp> pvcreate /dev/emcpowerd
pvcreate -- physical volume "/dev/emcpowerd" successfully created

Affiche les informations sur un PV (VGs attachés, etc) :

root@SpaceServer:/> pvdisplay /dev/emcpowerf
--- Physical volume ---
PV Name               /dev/emcpowerf
VG Name               vg_col1
PV Size               108.93 GB [228433792 secs] / NOT usable 32.19 MB [LVM: 141 KB]
PV#                   1
PV Status             available
Allocatable           yes (but full)
Cur LV                3
PE Size (KByte)       32768
Total PE              3484
Free PE               0
Allocated PE          3484
PV UUID               pmTDba-3lWV-8WEV-riwI-WkLG-odm3-1QoBpM

Permet de créer un VG sur un disque initialisé avec pvcreate.

root@SpaceServer:/tmp> pvcreate /dev/emcpowerd
pvcreate -- physical volume "/dev/emcpowerd" successfully created

root@SpaceServer:/tmp> vgcreate vg_apps /dev/emcpowerd

vgcreate -- INFO: using default physical extent size 32 MB
vgcreate -- INFO: maximum logical volume size is 2 Terabyte
vgcreate -- doing automatic backup of volume group "vg_apps"
vgcreate -- volume group "vg_apps" successfully created and activated

Permet d'ajouter un disque à un VG existant.

root@SpaceServer:/tmp> vgextend vg_apps /dev/emcpowera
vgextend -- INFO: maximum logical volume size is 2 Terabyte
vgextend -- doing automatic backup of volume group "vg_apps"
vgextend -- volume group "vg_apps" successfully extended

Permet de retirer un disque à un VG.

root@SpaceServer:/tmp> vgreduce vg_apps /dev/emcpowera
vgreduce -- doing automatic backup of volume group "vg_apps"
vgreduce -- volume group "vg_apps" successfully reduced by physical volume:
vgreduce -- /dev/emcpowera

Affiche les infos sur un VG donné, notamment les disques sur lesquels il se trouve.

root@SpaceServer:/etc/postfix> vgdisplay -v vg_dex4
--- Volume group ---
VG Name               vg_dex4
VG Access             read/write
VG Status             available/resizable
VG #                  4
MAX LV                256
Cur LV                9
Open LV               8
MAX LV Size           2 TB
Max PV                256
Cur PV                1
Act PV                1
VG Size               54.41 GB
PE Size               32 MB
Total PE              1741
Alloc PE / Size       1193 / 37.28 GB
Free  PE / Size       548 / 17.12 GB
VG UUID               MQ2P2L-S4Qi-Ig8q-LYW1-0vJN-V4LJ-b2CXcK

 --- Logical volume ---
 truncated

--- Physical volumes ---
PV Name (#)           /dev/emcpowerc (1)
PV Status             available / allocatable
Total PE / Free PE    1741 / 548

Recherche les VGs sur tous les disques et met à jour '/etc/lvmtab'.

root@SpaceServer:/tmp> vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found active volume group "rootvg"
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume group

Permet de changer les attributs d'un VG. En général on utilise vgchange -an rootvg pour désactiver un VG (on doit dans ce cas avoir démonté les FS) et vgchange -ay rootvg pour activer.

Permet de supprimer un VG (on doit d'abord le désactiver).

vgremove vg_apps

Permet de renommer un VG sans le désactiver. Attention à bien modifer /etc/fstab

vgrename vg_apps vg_appli

Permet de créer un LV sur un VG donné.

root@SpaceServer:/tmp> lvcreate -L 2G -n lv_test vg_apps
lvcreate -- doing automatic backup of "vg_apps"
lvcreate -- logical volume "/dev/vg_apps/lv_test" successfully created

Permet d'augmenter la taille du LV. Umount d'abord du FS

root@SpaceServer:/tmp> lvextend -L +1G /dev/vg_apps/lv_test
lvextend -- extending logical volume "/dev/vg_apps/lv_test" to 3 GB
lvextend -- doing automatic backup of volume group "vg_apps"
lvextend -- logical volume "/dev/vg_apps/lv_test" successfully extended

Permet de réduire la taille du LV. Attention on réduit d'abord le FS et seulement ensuite on peut réduire le LV.

root@SpaceServer:/tmp> lvreduce -L -1G /dev/vg_apps/lv_test
lvreduce -- WARNING: reducing active logical volume to 2 GB
lvreduce -- THIS MAY DESTROY YOUR DATA (filesystem etc.)
lvreduce -- do you really want to reduce "/dev/vg_apps/lv_test"? [y/n]: y
lvreduce -- doing automatic backup of volume group "vg_apps"
lvreduce -- logical volume "/dev/vg_apps/lv_test" successfully reduced

Affiche les différentes infos sur le LV. Utilisez -v pour avoir plus d'infos.

root@SpaceServer:/tmp> lvdisplay /dev/vg_apps/lv_test
--- Logical volume ---
LV Name                /dev/vg_apps/lv_test
VG Name                vg_apps
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 0
LV Size                2 GB
Current LE             64
Allocated LE           64
Allocation             next free
Read ahead sectors     1024
Block device           58:9

Permet de supprimer un LV.

root@SpaceServer:/tmp> lvremove /dev/vg_apps/lv_test
lvremove -- do you really want to remove "/dev/vg_apps/lv_test"? [y/n]: y
lvremove -- doing automatic backup of volume group "vg_apps"
lvremove -- logical volume "/dev/vg_apps/lv_test" successfully removed

Opérations courantes

note : on travaille ici en reiserfs. Pour l'ext3 utiliser mkfs.ext3 au lieu de mkreiserfs.

On créé d'abord le volume logique (LV), puis le filesystem (FS) à proprement parler. On finit par modifier le /etc/fstab

Création du LV :

lvcreate -L taille[M|G] -n nom_du_lv nom_du_vg
lvcreate -L 500M -n lv_apache vgdata

Création du FS (ici au format reiserfs):

mkreiserfs /dev/nom_du_vg/nom_du_lv
mkreiserfs /dev/vgdata/lv_apache

Il est possible d'augmenter à chaud sans avoir à démonter le FS. Dans ce cas on augmente d'abord le LV puis ensuite on augmente le FS.

Augmentation du LV :

lvextend -L +taille[M|G] /dev/nom_du_vg/nom_du_lv
lvextend -L +500M /dev/vgdata/lv_apache

Augmentation du FS :

resize_reiserfs -s+taille[M|G] /dev/nom_du_vg/nom_du_lv
reiserfs -s+500M /dev/vgdata/lv_apache

Il est obligatoire de démonter le FS pour la réduction. On réduit d'abord le FS puis le LV.

Démontage du FS :

umount /nom_du_fs
umount /apache

Réduction du FS :

resize_reiserfs -s-taille[M|G] /dev/nom_du_vg/nom_du_lv
resize_reiserfs -s-500M /dev/vgdata/lv_apache

Réduction du LV :

lvreduce -L -taille[M|G] /dev/nom_du_vg/nom_du_lv
lvreduce -L 500M /dev/vgdata/lv_apache

Remontage du FS :

mount /nom_du_fs
mount /apache

On créé d'abord un LV sur lequel on positionnera un rawdevice :

lvcreate -L 16G -n lv_raw_01 vg_data

Lancer la commande raw pour binder les rawdevices :

raw /dev/raw/rawX /dev/vg_data/lv_raw_01

Renseigner le fichier /etc/sysconfig/rawdevices

Configurer le démarrage des raws au boot

/etc/init.d/rawdevices start
  • Vérifier l'existant:
/usr/sbin/hpacucli

→ controller all show

Smart Array 6i in Slot 0      ()

→ controller slot=0 physicaldrive all show

Smart Array 6i in Slot 0

  array A
   physicaldrive 2:0   (port 2:id 0 , Parallel SCSI, 72.8 GB, OK)
   physicaldrive 2:1   (port 2:id 1 , Parallel SCSI, 72.8 GB, OK)

  array B
   physicaldrive 2:2   (port 2:id 2 , Parallel SCSI, 72.8 GB, OK)
   physicaldrive 2:3   (port 2:id 3 , Parallel SCSI, 72.8 GB, OK)

→ controller slot=0 logicaldrive all show

Smart Array 6i in Slot 0

  array A
   logicaldrive 1 (67.8 GB, 1+0, OK)

  array B
   logicaldrive 2 (67.8 GB, 1+0, OK)
  • Créer un nouveau RAID:
/usr/sbin/hpacucli

→ controller slot=0 create type=logicaldrive drives=allunassigned raid=1+0

Puis pvcreate sur le nouveau disque.

  • Etendre un RAID existant:
/usr/sbin/hpacucli

→ controller slot=0 array B modify size=max

Reboot du serveur pour prise en compte au niveau système puis pvresize pour étendre le LVM.

lvcreate --type mirror -L 128MB -m 1 --mirrorlog mirrored -n vol1 testvg

Soit le vg suivant vg_mirror :

Volume groupe : vg_mirror

Volume(s) physique(s) : 2
PE : totaux = 223072 Mo, alloues : 0 Mo, libres : 223072 Mo
PV : /dev/emcpowerm         ,tot_sz = 111536 Mo   ,lib_sz  = 111536 Mo
PV : /dev/emcpowern         ,tot_sz = 111536 Mo   ,lib_sz  = 111536 Mo

Par défaut le lvm a besoin de 3 disques : 2 pour mirrorer les datas et un 3ème pour la log mais du coup si on perd ce disque on perd les datas … Autant le mettre en RAM (il sera recréé à chaque reboot par exemple).

root@serverl1101561:/# lvcreate -m 1 --corelog -L 20G -n lv_one vg_mirror
  Logical volume "lv_one" created

Volume groupe : vg_mirror

Volume(s) physique(s) : 2
PE : totaux = 223072 Mo, alloues : 40960 Mo, libres : 182112 Mo
PV : /dev/emcpowerm         ,tot_sz = 111536 Mo   ,lib_sz  = 91056 Mo
PV : /dev/emcpowern         ,tot_sz = 111536 Mo   ,lib_sz  = 91056 Mo

Volume(s) logique(s)  : 3
LV : lv_one                 ,log_sz = 20480 Mo,   sur   ne_mimage_0 ne_mimage_1
LV : lv_one_mimage_0        ,log_sz = 20480 Mo,   sur
LV : lv_one_mimage_1        ,log_sz = 20480 Mo,   sur

root@server1101561:/# mkfs.ext3  /dev/vg_mirror/lv_one
root@server1101561:/# mount /dev/vg_mirror/lv_one /mnt

Malheureusement on ne peut pas étendre le LV à chaud, il faut démonter le FS puis faire un lvchange -an ce qui n'est pas très pratique.

root@server1101561:/# lvextend -L +10G /dev/vg_mirror/lv_one
  Extending 2 mirror images.
  Mirrors cannot be resized while active yet.

Une solution existe néanmoins. On supprime une patte du mirroir, on étend et on réintègre la patte en question :

root@serverl1101561:/# lvconvert -m 0 /dev/vg_mirror/lv_one
  Logical volume lv_one converted.

root@server1101561:/# lvextend -L +10G /dev/vg_mirror/lv_one
  Extending logical volume lv_one to 30.00 GB
  Logical volume lv_one successfully resized

root@server1101561:/# lvconvert -m 1 --corelog /dev/vg_mirror/lv_one
  Logical volume lv_one converted.

On peut voir le statut de la resynchro :

root@server1101561:/var/log# lvs -a /dev/vg_mirror/lv_one
  LV     VG        Attr   LSize  Origin Snap%  Move Log Copy%
  lv_one vg_mirror mwi-ao 50.00G                          9.03

On vérifie le résultat :

Volume groupe : vg_mirror

Volume(s) physique(s) : 2
PE : totaux = 223072 Mo, alloues : 61440 Mo, libres : 161632 Mo
PV : /dev/emcpowerm         ,tot_sz = 111536 Mo   ,lib_sz  = 80816 Mo
PV : /dev/emcpowern         ,tot_sz = 111536 Mo   ,lib_sz  = 80816 Mo

Volume(s) logique(s)  : 3
LV : lv_one                 ,log_sz = 30720 Mo,   sur   ne_mimage_0 ne_mimage_1
LV : lv_one_mimage_0        ,log_sz = 30720 Mo,   sur
LV : lv_one_mimage_1        ,log_sz = 30720 Mo,   sur

On étend le FS :

root@server1101561:/# ext2online /mnt/
ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b
Cas 1

⇒ On veut déplacer tous les LVs du disque emcpowerm vers emcpowern, à chaud.

  • Soit le vg_appli constitué du disque emcpowerm :
root@server1101561:~# vgdisplay -v vg_appli 2>/dev/null|grep "PV Name"
  PV Name               /dev/emcpowerm
  • On rajoute le disque emcpowern au vg_appli :
root@server1101561:~# pvcreate /dev/emcpowern
  Physical volume "/dev/emcpowern" successfully created

root@server1101561:~# vgextend vg_appli /dev/emcpowern
  Volume group "vg_appli" successfully extended
  • Soient les LVs suivants :
root@server1101561:~# ls -1 /dev/vg_appli
lv_data1
lv_data2
lv_data3
lv_data4
lv_data5
  • On utilise pvmove pour déplacer ces LVs, à chaud :
root@server1101561:~# ls -1 /dev/vg_appli|while read i
> do
> pvmove -n $i /dev/emcpowerm /dev/emcpowern
> echo "$i moved \!"
> done
  /dev/emcpowerm: Moved: 2.0%
  /dev/emcpowerm: Moved: 4.2%
  /dev/emcpowerm: Moved: 6.5%
  /dev/emcpowerm: Moved: 8.8%
  /dev/emcpowerm: Moved: 11.0%
...
  • On supprime le disque emcpowerm du vg_appli :
vgreduce vg_appli /dev/emcpowerm 
vgscan
vgcfgbackup vg_appli
Cas 2

⇒ On veut déplacer certains LVs du disque emcpowerm vers emcpowern avec le moins d'indispo possible et faire un nouveau VG vg_appli2 avec les LVs déplacés.

On reprend la même procédure que précédemment. Une fois tous les LVs déplacés intégralement sur le nouveau disque il faut désactiver le VG (et donc avoir démonter tous les FS au préalable et désactiver les éventuels raws) :

root@server1101561:~# vgchange -an vg_appli
  0 logical volume(s) in volume group "vg_appli" now active

root@server1101561:~# vgsplit vg_appli vg_appli2 /dev/emcpowern
  Volume group "vg_appli2" successfully split from "vg_appli"

Et voila :

root@server1101561:~# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "vg_appli2" using metadata type lvm2
  Found volume group "vg_appli" using metadata type lvm2
  Found volume group "rootvg" using metadata type lvm2

Ensuite on active les VGs avec vgchange -ay et on remonte les LVs.

root@server2311827:/# lvmdiskscan  |grep dm- |tail
  /dev/dm-23     [        1.00 GB]
  /dev/dm-24     [        3.44 GB]
  /dev/dm-25     [        1.47 GB]
  /dev/dm-26     [        1.47 GB]
  /dev/dm-27     [      160.00 MB]
  /dev/dm-28     [      224.00 MB]
  /dev/dm-29     [        5.00 GB]
  /dev/dm-30     [        5.00 GB]
  /dev/dm-31     [      288.00 MB]
  /dev/dm-32     [       39.06 GB]

On peut les confondre avec des devices multipath, pour être sur on peut lancer un multipath -ll et effectuer la correspondance. Si la commande n'existe pas ou ne rend rien c'est tout simple que linux créé un device dm-* pour chaque LV créé. Pour checker :

  • On récupère les minor/major :
root@server2311827:/#  ls -l /dev/dm-27
brw-r-----  1 root root 253, 27 Apr 17 09:39 /dev/dm-27
  • On check dans les VGs :
root@server2311827:/# vgdisplay -v 2>/dev/null |grep 253:27 -B 11|grep "LV Name"
  LV Name                /dev/rootvg/lv_wls103_d1

Metadevices (RAID 1 logiciel)

  • Créer les metadevices :
mdadm --create /dev/md0 -l 1 --raid-devices=2 /dev/emcpowera2 /dev/emcpowerc2
mdadm --create /dev/md1 -l 1 --raid-devices=2 /dev/emcpowerb /dev/emcpowerd
  • Créer un RAID 1 avec un seul disque au début :
mdadm --create /dev/md0 -l 1 --raid-devices=2 /dev/sda2 missing
  • Démarrer les metadevices :
mdadm --assemble /dev/md0 /dev/emcpowera2 /dev/emcpowerc2
mdadm --assemble /dev/md1 /dev/emcpowerb /dev/emcpowerd
  • Arrêter les metadevices :
mdadm --stop /dev/md0
mdadm --stop /dev/md1
  • Dans le fichier /etc/mdadm.conf rajouter :
DEVICE /dev/emcpowerb /dev/emcpowerd
DEVICE /dev/emcpowera2 /dev/emcpowerc2
  • Puis pour vérifier :
mdadm --examine --scan -c /etc/mdadm.conf

root@SpaceServer:/root> mdadm --examine --scan -c /etc/mdadm.conf
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=cdeabe60:356153ce:16bed617:874f97db
   devices=/dev/emcpowera2,/dev/emcpowerc2
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=66458bd1:5bb9acd4:18503815:b36812b6
   devices=/dev/emcpowerb,/dev/emcpowerd
root@spaceServer:/mnt> mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90.00
  Creation Time : Tue Apr 17 16:18:46 2007
     Raid Level : raid1
     Array Size : 57108416 (54.46 GiB 58.48 GB)
    Device Size : 57108416 (54.46 GiB 58.48 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Thu Apr 19 12:20:23 2007
          State : dirty, no-errors -----------------------------> le dirty c'est "normal" :-]
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
  • Ensuite si tout est ok on peut écrire dans le fichier :
mdadm --examine --scan -c /etc/mdadm.conf >> /etc/mdadm.conf
  • Supprimer un device d'un RAID :

⇒ on le passe en failed

root@SpaceServer:/mnt>  mdadm /dev/md0 --fail /dev/emcpowerb
mdadm: set /dev/emcpowerb faulty in /dev/md0

⇒ on le supprime

root@SpaceServer:/mnt>  mdadm /dev/md0 --remove /dev/emcpowerb
mdadm: hot removed /dev/emcpowerb

root@SpaceServer:/mnt> mdadm --detail /dev/md0
/dev/md0:
 
    Number   Major   Minor   RaidDevice State
       0       0        0        0      faulty removed
       1     232       48        1      active sync   /dev/emcpowerd
  • Ensuite on peut rajouter un nouveau device
root@SpaceServer:/mnt/ben> mdadm /dev/md0 --add /dev/emcpowerb
mdadm: hot added /dev/emcpowerb

Hop ! Synchro en cours :

root@SpaceServer:/mnt/ben> cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
Event: 11
md1 : active raid1 emcpowera2[0] emcpowerc2[1]
      56902144 blocks [2/2] [UU]

md0 : active raid1 emcpowerb[2] emcpowerd[1]
      57108416 blocks [2/1] [_U]
      [>....................]  recovery =  0.2% (150040/57108416) finish=88.5min speed=10717K/sec
unused devices: <none>

Par défaut la vitesse de reconstruction est limitée pour des soucis de perfs, on peut le voir dans la log :

md: syncing RAID array md0
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwith (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 14277056 blocks.

On peut augmenter la vitesse via /proc/sys/dev/raid/speed_limit_min :

echo 25000 >> /proc/sys/dev/raid/speed_limit_min

On voit tout de suite la différence :

Avant :

root@server9002737:/mnt/ben# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 emcpowerd[1] emcpowere[0]
      14277056 blocks [2/2] [UU]
      [======>..............]  resync = 33.7% (4821888/14277056) finish=151.5min speed=1036K/sec

Après:

root@server9002737:/mnt/ben# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 emcpowerd[1] emcpowere[0]
      14277056 blocks [2/2] [UU]
      [================>....]  resync = 82.6% (11803776/14277056) finish=1.6min speed=25004K/sec
  • On peut aussi retailler un métadevice (augmenter ou réduire) :
mdadm --grow size=50G /dev/md0
pvresize /dev/md0

Troubleshooting

On récupère les infos minor / major du device :

[root@SomeMachine]# ls -l /dev/dm-12
brw-r-----  1 root root 253, 12 Jun 24 11:27 /dev/dm-12

On peut également trouver les infos sous /dev/mapper et utiliser /proc/partitions.

On cherche le LV correspondant :

[root@SomeMachine]# lvdisplay -v |grep -B 13 "253:12"
File descriptor 3 left open
    Finding all logical volumes

  --- Logical volume ---
  LV Name                /dev/vg_oraORACLESID/lv_oracle
  VG Name                vg_oraORACLESID
  LV UUID                6Re4id-CaYP-OcML-z3J7-g4lG-AEtu-PFXLtO
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                512.00 MB
  Current LE             128
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:12

On en déduit le FS grâce au /etc/fstab ou au fichier de démarrage MC Service Guard (comme ici) :

[root@SomeMachine]# grep "vg_oraORACLE_SID/lv_oracle" cl_*/*.sh
LV[0]="/dev/vg_oraORACLE_SID/lv_oracle"; FS[0]="/apps/oracle"; FS_TYPE[0]="ext3"; FS_MOUNT_OPT[0]=""

Soit l'erreur suivante dans /var/log/messages :

Feb 19 09:28:44 SomeMachine kernel: 3a:0c: rw=0, want=652360104, limit=167772160

Pas forcément très clair … Ce qui nous intéresse ici c'est 3a:0c, on convertit de l'hexa vers le décimal :

Hexa Décimal
3a 58
0c 12

Il s'agit du device LVM (58,12) :

root@SomeMachine:/tmp> lvscan |grep ACTIVE|awk '{print $4}'|xargs lvdisplay|grep 58:12 -B 13

--- Logical volume ---
LV Name                /dev/vg_col1/lv_sybasedata1
VG Name                vg_col1
LV Write Access        read/write
LV Status              available
LV #                   3
# open                 1
LV Size                160 GB
Current LE             5120
Allocated LE           5120
Allocation             next free
Read ahead sectors     1024
Block device           58:12

Ensuite on retrouve le FS associé via le fichier /etc/fstab ou le fichier de démarrage cluster (MC Service Guard par exemple).

On peut parfois avoir cette erreur si un disque a été retiré à l'arrache :

Couldn't find device with uuid 'sAK55E-35qf-Ffs5-ju6g-ZCnN-ojwi-BPb1CJ'.
Couldn't find all physical volumes for volume group vg_oap.

Pour y remédier :

vgreduce --removemissing --test vg_oap

vgreduce --removemissing vg_oap
  Couldn't find device with uuid 'sAK55E-35qf-Ffs5-ju6g-ZCnN-ojwi-BPb1CJ'.
  Couldn't find all physical volumes for volume group vg_oap.
  Couldn't find device with uuid 'sAK55E-35qf-Ffs5-ju6g-ZCnN-ojwi-BPb1CJ'.
  Couldn't find all physical volumes for volume group vg_oap.
  Couldn't find device with uuid 'sAK55E-35qf-Ffs5-ju6g-ZCnN-ojwi-BPb1CJ'.
  Couldn't find all physical volumes for volume group vg_oap.
  Couldn't find device with uuid 'sAK55E-35qf-Ffs5-ju6g-ZCnN-ojwi-BPb1CJ'.
  Couldn't find all physical volumes for volume group vg_oap.
  Couldn't find device with uuid 'sAK55E-35qf-Ffs5-ju6g-ZCnN-ojwi-BPb1CJ'.
  Couldn't find device with uuid 'sAK55E-35qf-Ffs5-ju6g-ZCnN-ojwi-BPb1CJ'.
  Couldn't find device with uuid 'sAK55E-35qf-Ffs5-ju6g-ZCnN-ojwi-BPb1CJ'.
  Couldn't find device with uuid 'sAK55E-35qf-Ffs5-ju6g-ZCnN-ojwi-BPb1CJ'.
  Wrote out consistent volume group vg_oap

Puis un petit vgscan pour vérifer.

Parfois on peut avoir le message d'erreur ci-dessous :

vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group from physical volume(s)

Pour y remédier on peut tenter la commande vgcfgrestore et utiliser un backup précédent. Un backup est généré :

  • dans /etc/lvmconf sous RHEL3
  • dans /etc/lvm/backup sous RHEL4 / Debian and co

On vérifie le VG :

root@server1106215:/etc/lvmconf> vgscan
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found active volume group "rootvg"
vgscan -- found inactive volume group "vg_toto"
vgscan -- only found 0 of 160 LEs for LV /dev/vg_titi/lv_srec (0)
vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "vg_titi" from physical volume(s)
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume groups

On restaure le conf du VG :

root@server1106215:/etc/lvmconf> vgcfgrestore -f vg_titi.conf -n vg_titi "/dev/emcpowerd"
vgcfgrestore -- size of physical volume /dev/emcpowerd differs from backup

Pour ignorer les contraintes de taille (de toute façon au point où on en est) :

root@server1106215:/etc/lvmconf> vgcfgrestore -i -f vg_titi.conf -n vg_titi "/dev/emcpowerd"
vgcfgrestore -- forcing write of VGDA of "vg_titi" to physical volume "/dev/emcpowerd"
vgcfgrestore -- ignoring size mismatches
vgcfgrestore -- VGDA for "vg_titi" successfully restored to physical volume "/dev/emcpowerd"
vgcfgrestore -- you may not have an actual backup of restored volume group "vg_titi"

Juste pour se proteger, on fait un vgcfgbackup sur les 2 noeuds.

root@server1106216:/etc/lvmconf> ls -l /etc/lvmconf/vg_titi.conf
-rw-r-----    1 root     root       166924 Feb  1 11:15 /etc/lvmconf/vg_titi.conf
root@server1106215:/etc/lvmconf> ls -l *conf
-rw-r-----    1 root     root       166924 Feb  1 11:14 vg_titi.conf

:!: Parfois il faut lancer le vgcfgrestore avec un autre disque du VG jusqu'à ce que ça passe (dans le cas où le VG est sur plusieurs disques), la commande pvscan permet de lister les PVs.

  • Désactiver temporairement l'écriture du kernel logger dans kern.log (/etc/syslogd.conf).
echo 1 > /proc/sys/vm/block_dump
while true; do dmesg -c; sleep 1; done
echo 0 > /proc/sys/vm/block_dump

Lorsque des disques SAN sont rajoutés sur une machine Linux alors qu'ils n'ont pas été formatés on peut avoir des erreurs de Duplicate VG name notamment avec le vg_apps. Cela provient du fait que les disques ajoutés non pas été formatés et qu'ils contenaient dejà un vg_apps. Pour que ce soit encore plus rock n' roll le vg_apps importé n'a pas tous ses disques. Par exemple :

→ le vg_apps déjà existant et complet :

  --- Volume group ---
  VG Name               vg_apps
  VG UUID               sz0iLr-t1jV-iaJf-8xLM-1clh-FK2L-21Zeyk

  --- Physical volumes ---
  PV Name               /dev/dm-21
  PV UUID               llalr9-8I9F-y3st-mcCa-QkZ7-QDX0-ZAHI3O

→ le vg_apps incomplet et importé par la rajout du disque SAN :

  --- Volume group ---
  VG Name               vg_apps
  VG UUID               Ca5e4x-xbqq-6j5V-x9vG-Dvdb-xixF-Lq2XUa

  --- Physical volumes ---
  PV Name               unknown device
  PV UUID               jAnT2n-BoUf-Cazf-1SrY-sVx4-3dzn-J83scd
  PV Status             allocatable
  Total PE / Free PE    13942 / 0

  PV Name               /dev/dm-18
  PV UUID               14VTx7-IZYM-yejh-zCf5-lkHM-qDg7-DGLl0c
  PV Status             allocatable
  Total PE / Free PE    27884 / 577

  PV Name               unknown device
  PV UUID               JUOqyk-t6Ob-ciL6-IB4X-k23y-fQNv-KQLd2v
  PV Status             allocatable
  Total PE / Free PE    13942 / 3702

On remarque les unknown device (chaque disque du VG contient toutes les infos du VG dans son entête). Par ailleurs chaque fois qu'un commande LVM est lancé la machine vomit des erreurs et on ne peut plus bosser sur le vg_apps car il est vu en double par l'OS.

Pour vérifier que c'est bien le /dev/-dm18 qui pose problème on peut visualiser les LVs présents :

pvdisplay -m /dev/dm-18

On vérifie qu'aucun FS rétourné par la commande n'est monté.

Pour résoudre le problème :

vgrename Ca5e4x-xbqq-6j5V-x9vG-Dvdb-xixF-Lq2XUa vg_apps_KO => on renomme le VG avec son VG UUID
vgchange -a n vg_apps_KO				   => on désactive le VG
vgremove vg_apps_KO					   => on bute le VG
pvremove -ff /dev/dm-18					   => on bute l'entête LVM du device

Sauf que dans le cas que j'ai rencontré je n'ai pas pu renommer le VG car il était en cours d'utilisation … En fait lors du vgscan un LV du VG foireux devait avoir les mêmes minor/major et a été importé dans le bon VG :

root@parsl2414967:/tmp# ls -l /dev/vg_apps/lv_dba
lrwxrwxrwx 1 root root 26 Nov 17 18:08 /dev/vg_apps/lv_dba -> /dev/mapper/vg_apps-lv_dba

L'OS le voyait actif car le bon vg_apps était actif et donc impossible de faire quoique ce soit sur le VG corrompu. La commande lvremove ne passait donc pas (une sorte de LV fantôme). Pour le supprimer réellement il faut utiliser la commande de bas niveau dmsetup qui permet d'accéder aux devices multipath et au LVM. On le supprime :

dmsetup info -c |grep lv_dba	=> on récupère le nom du LV au format dmsetup
dmsetup remove vg_apps-lv_dba	=> on le supprime réellemment

Ensuite on peut reprendre la manip ci-dessus en renommant le VG. Si jamais ça ne passe pas on peut aussi supprimer le device /dev/dm-18 :

mpath8 (360060480000290103021533030353143) dm-18 EMC,SYMMETRIX
[size=109G][features=0][hwhandler=0][rw]
\_ round-robin 0 [prio=2][active]
 \_ 3:0:0:45 sdj 8:144 [active][ready]
 \_ 4:0:0:45 sds 65:32 [active][ready]

dmsetup remove mpath8			=> on supprime le device					
pvremove /dev/sdj /dev/sds		=> on vire les infos LVM sur les 2 chemins

Un vgscan permet de remettre tout d'aplomb. Le device /dev/dm-18 est maintenant vierge de toutes infos LVM et on peut enfin bosser.

Cette méthode permet de ne pas rebooter le serveur ni d'arrêter les applis qui tournent.

May 31 01:00:04 server3006361 kernel: scsi3 (0:0): rejecting I/O to offline device
May 31 01:00:04 server3006361 kernel: SCSI error: host 3 id 0 lun 0 return code = 4000000
May 31 01:00:04 server3006361 kernel:    Sense class 0, sense error 0, extended sense 0
May 31 01:00:05 server3006361 su(pam_unix)[2593]: session opened for user root by (uid=0)
May 31 01:00:06 server3006361 kernel: scsi3 (0:0): rejecting I/O to offline device
May 31 01:00:06 server3006361 kernel: SCSI error: host 3 id 0 lun 0 return code = 4000000
May 31 01:00:06 server3006361 kernel:    Sense class 0, sense error 0, extended sense 0
May 31 01:00:06 server3006361 kernel: scsi3 (0:0): rejecting I/O to offline device
May 31 01:00:06 server3006361 kernel: SCSI error: host 3 id 0 lun 0 return code = 4000000
May 31 01:00:06 server3006361 kernel:    Sense class 0, sense error 0, extended sense 0
May 31 01:00:06 server3006361 kernel: scsi3 (0:0): rejecting I/O to offline device
May 31 01:00:06 server3006361 kernel: SCSI error: host 3 id 0 lun 0 return code = 4000000
May 31 01:00:06 server3006361 kernel:    Sense class 0, sense error 0, extended sense 0
root@server3006361:PRODUCTION:/var/log# cat /proc/scsi/scsi |egrep -A 2 "scsi3"
Host: scsi3 Channel: 00 Id: 00 Lun: 00
  Vendor: Dell     Model: Virtual  CDROM   Rev: 123
  Type:   CD-ROM                           ANSI SCSI revision: 02
[root@localhost ~]# lsscsi --hosts
[0]    ata_piix
[1]    ata_piix
[2]    ahci
[root@localhost ~]# lsblk -S
NAME HCTL       TYPE VENDOR   MODEL             REV TRAN
sda  2:0:0:0    disk ATA      VBOX HARDDISK    1.0  sata
sr0  1:0:0:0    rom  VBOX     CD-ROM           1.0  ata
  • informatique/nix/linux/linux_lvm.txt
  • Dernière modification : 2018/01/11 08:38
  • de ben