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
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
/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)
/usr/sbin/hpacucli
→ controller slot=0 create type=logicaldrive drives=allunassigned raid=1+0
Puis pvcreate sur le nouveau disque.
/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
⇒ On veut déplacer tous les LVs du disque emcpowerm vers emcpowern, à chaud.
root@server1101561:~# vgdisplay -v vg_appli 2>/dev/null|grep "PV Name" PV Name /dev/emcpowerm
root@server1101561:~# pvcreate /dev/emcpowern Physical volume "/dev/emcpowern" successfully created root@server1101561:~# vgextend vg_appli /dev/emcpowern Volume group "vg_appli" successfully extended
root@server1101561:~# ls -1 /dev/vg_appli lv_data1 lv_data2 lv_data3 lv_data4 lv_data5
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% ...
vgreduce vg_appli /dev/emcpowerm vgscan vgcfgbackup vg_appli
⇒ 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 :
root@server2311827:/# ls -l /dev/dm-27 brw-r----- 1 root root 253, 27 Apr 17 09:39 /dev/dm-27
root@server2311827:/# vgdisplay -v 2>/dev/null |grep 253:27 -B 11|grep "LV Name" LV Name /dev/rootvg/lv_wls103_d1
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
mdadm --create /dev/md0 -l 1 --raid-devices=2 /dev/sda2 missing
mdadm --assemble /dev/md0 /dev/emcpowera2 /dev/emcpowerc2 mdadm --assemble /dev/md1 /dev/emcpowerb /dev/emcpowerd
mdadm --stop /dev/md0 mdadm --stop /dev/md1
DEVICE /dev/emcpowerb /dev/emcpowerd DEVICE /dev/emcpowera2 /dev/emcpowerc2
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
mdadm --examine --scan -c /etc/mdadm.conf >> /etc/mdadm.conf
⇒ 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
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
mdadm --grow size=50G /dev/md0 pvresize /dev/md0
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é :
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.
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