VMWare resize disk avec LVM

Avec VMWARE souvent, on a besoin d'etendre le disque virtuel d'une VM.
Plutot que de creer un nouveau disque, le plus simple et de resize le disque existant.

Dans la console Vcenter augmenter la taille du disque souhaite.

Puis a niveau de l'OS,il faut faire reconnaire a la VM la taille du nouveau disque, sdX etait son disque.
Pour connaitre l'emplacement du disque on peut utiliser lsscsi ou regarder les dernieres entrees de dmesg.
Pour rescan :

echo 1 > /sys/block/sdX/device/rescan

Si tout va bien, on peut faire un pvresize pour faire reconnaitre a LVM la nouvelle taille

pvresize /dev/sdX

Si tout va bien l'espace disponible apparait dans VGS et dans ce cas on peut extend le logical volume, par example :

lvextend VGname/LVname -l +100%FREE

Enfin reste a augmenter le filesystem avec simplement un resize2fs et le tour est joue.


Alternative, si on souhaite augmenter la partition d'un disque.

Dans ce cas, on rescan puis cfdisk /dev/sdX pour verifier l'espace libre du disque. Eliminer la partition a etendre, puis la recreer avec le meme type (le plus souvent 8e pour LVM), sauvegarder, partprobe pour reconnaitre la nouvelle taille de la partition. Puis suivre les meme etapes, pvresize, lvextend. 

Restore LVM metadata

Je partage ma récente aventure, après le reboot d'un serveur NFS qui exporte plus de 10Tb en 69 Filesystem.
Au redémarrage, seuls 60 FS sont présents, neufs sont absents.
Par exemple :
PV unknown device               VG vgFS58        lvm2 [50.00 GB / 0    free]
mount: special device /dev/mapper/vgFS58-lvfs58 does not exist

Passé les doutes, l'analyse du multipath montre que les FS sont bien présenté au serveur par le NAS mais que les VG sont indiqué comme partial.

vgFS58        8   1   0 wz-pn- 409.97G      0 

Il ne s'agit pas de d'activer le VG ou le LV avec vgchange -ay ou lvchange -ay mais de restorer la métadata qui a disparu.

A la recherche des devices perdus

Commence alors la recherche des devices perdus, pour le FS58 il s'agit de 4 devices.
  unknown device             vgFS58      lvm2 a-    50.00G      0 
  unknown device             vgFS58      lvm2 a-    50.00G      0 
  unknown device             vgFS58      lvm2 a-    50.00G      0 
  unknown device             vgFS58      lvm2 a-    50.00G      0

Il fautt retrouver le device et réapliquer la metadata manquante.
Multipath indique les devices :

# multipath -l | grep fs58
lvm6fs58 (36005076305ffc0290000000000002539) dm-286 xx,xx
lvm1fs58 (36005076305ffc0290000000000002535) dm-269 xx,xx
lvm7fs58 (36005076308ffc536000000000000066b) dm-187 xx,xx

Pour vérifier l'état d'un device :
# pvck /dev/dm-269
Could not find LVM label on /dev/dm-269

On est donc sur que le device ne contient pas de metadata, il faut donc la restaurer.
Je sais qu'il s'agit du premier device, pour rechercher dans son id, l'info dans /etc/lvm/archive/vgFS58_00009.vg 

Il reste à l'appliquer :
# pvcreate --uuid "p5bjql-fCXc-vTCe-KBuF-2DgF-X2rl-UfZCti" --restorefile /etc/lvm/archive/vgFS58_00009.vg /dev/dm-269

Bingo !

Une fois toutes les métadatas restaurés, le VG redevient disponible :
# vgs vgFS58
  VG     #PV #LV #SN Attr   VSize   VFree
  vgFS58   8   1   0 wz--n- 409.97G    0 

On réactive le LV
# lvchange -ay vgFS58/lvfs58

Reste à scan le FS
# e2fsck /dev/mapper/vgFS58-lvfs58
e2fsck 1.41.9 (22-Aug-2009)
e2fsck: Group descriptors look bad... trying backup blocks...
/dev/mapper/vgFS58-lvfs58: recovering journal
e2fsck: unable to set superblock flags on /dev/mapper/vgFS58-lvfs58

# e2fsck /dev/mapper/vgFS58-lvfs58  -y
e2fsck 1.41.9 (22-Aug-2009)
One or more block group descriptor checksums are invalid.  Fix? yes

Et le tour est joué, on peut mount avec succès le FS.

Restait plus que 8 autres FS et environ 20 devices.
Mais tout c'est bien déroulé, il a été possible de récupérer l'accès aux données.

En résumé :

• Rechercher des informations : 

# multipath -l | grep fs58
# grep -i id /etc/lvm/archive/vgFS58_00009.vg
# pvck /dev/dm-269

• Restauration metadata

# pvcreate --uuid "p5bjql-fCXc-vTCe-KBuF-2DgF-X2rl-UfZCti" --restorefile /etc/lvm/archive/vgFS58_00009.vg /dev/dm-269

• Contrôle

# vgs vgFS58

• Activacion LV

# lvchange -ay vgFS58/lvfs58

• Vérification du FS

# e2fsck /dev/mapper/vgFS58-lvfs58  -y

• Disponibilité du FS

#mount /dev/mapper/vgFS58-lvfs58 /FS58

Jouer avec les FS et les clusters

Je réinstalle un cluster, je souhaite monter mon FS ext4 qui était en cluster pour récupérer les données du backup.

Mais impossible :
Skipping Cluster Volume group

Remede, desactivé le lock lvm pour ce VG, puis l'activer, l'importer et le monter.
vgchange -cn vgname --config 'global {locking_type = 0}'
vgchange -ay vgname
vgimport vgname
lvchange -ay /dev/mapper/vgname-backup--gfs


Et maintenant comment faire pour monter directement dans mon nouveau cluster mon FS GFS2 ?
Erreur :
/sbin/mount.gfs: fs is for a different cluster 

/sbin/mount.gfs: error mounting lockproto lock_dlm

Facile, on récrit sur la metadata, la table du lock.

 gfs2_tool sb /dev/mapper/vgGFS-lvGFS table nouveacluster:nouveaupointdemontage

 mount /dev/mapper/vgGFS-lvGFS /u01/

Proxmox, VZDUMP et LVM

En ce moment j'utilise beaucoup Proxmox, une solution Debian intégrant OpenVZ et QEMU/KVM.

Proxmox est très puissant, très agile et permet de virtualiser des machines Linux et Windows sans impact sur les performances avec de nombreuses fonctionnalités : 

• Cluster, 
• Backup, 
• Web interface de management,
• Template personnalité pour facilité la mise en production.

Proxmox permet de faire tout ça et gratuitement bien sûr.

Beaucoup de hosting compagnies l'utilisent ou bien seulement OpenVZ, la plus part des VPS sont des containers ou des VM Xen.

Une des qualités principales de Proxmox est VZDUMP.

VZDUMP permet de sauvegarder le serveur virtuel selon 3 modes :

• Arrêt du serveur
• Interruption du serveur, comme un freeze
• Snapshot sans arrêt du serveur.

Évidement le mode snapshot est le plus intéressant mais curieusement avec une installation typique de Proxmox ce mode n'est pas possible car pour effectuer le snapshot il faut

• Une partition source, un volume logique utilisant LVM
• Une espace non utilisé, pour créer le volume logique snapshot
• Une partition cible qui va recevoir le backup

Or la partition cible n'existe pas.

Proxmox installe

1 Volume groupe : PVE, conserve de l'espace libre et également ;

3 volumes logique :

• /
• swap
• /var/lib/vz, qui contient les données de VZ (les serveurs virtuels)

Pour utiliser Vzdump en snapshot il faut conserver l'espace libre et créer une nouvelle partition Backup.

Étapes à suivre :

Arrêter les services VZ	/etc/init.d/vz stop (arrêter tous les VM et VE)
Démonter la partition Data	umount /var/lib/vz
Vérifier le filesystem de la partition	e2fsck /dev/pve/data
Réduire le filesystem de la partition Réduire le Volume logique	lvreduce -r -L -500G /dev/pve/data
Vérifier le filesystem de la partition	e2fsck /dev/pve/data
Remonter la partition	mount /var/lib/vz
Créer le volume logique Backup	lvcreate -L 500G -n backup pve
Créer le filesystem de Backup	mkfs.ext3 -m 1 -v /dev/pve/backup
Créer le point de montage	mkdir /var/lib/vz/backup
Monter le disque	mount /dev/pve/backup /var/lib/vz/backup/
Démarrer les services VZ	/etc/init.d/vz start

Ne pas oublier d'ajouter /var/lib/vz/backup dans /etc/fstab

Pour éviter d'avoir un problèmes plutôt que d'utiliser efsresize, 

je préfère utiliser lvreduce avec l'option -r pour efsresize.

Évidement l'inverse est possible avec lvextend.