Bonjour,
J’ai eu le même type de problèmatique pour des VM hyperV que j’ai adressé de la façon suivante (partitionnement GPT) :
-
Je créé une nouvelle (4eme dans mon cas) partition type lvm (8e) avec tout l’espace disque supplémentaire (sgdisk
--move-second-header --largest-new=4 --typecode=4:8E00 /dev/sda)
-
Je mets à jour la table de partition (partprobe)
-
Je crée un nouveau PV sur cette nouvelle partition (pvcreate /dev/sda4)
-
J’ajoute ce nouveau PV dans mon VG (vgextend vg01 /dev/sda4)
-
J’étends mon LV avec tout le nouvel espace disque de mon VG (racine / dans mon cas) (lvextend -l +100%FREE /dev/vg01/root)
-
J’étends mon filesystem ext4 pour prendre en compte le nouvel espace disque de mon LV (resize2fs /dev/vg01/root)
Cette méthode fonctionne sans reboot
J’avais eu une autre approche pour ne pas à avoir à recréer un nouveau PV mais pas assez propre à mon goût et qui nécessitait un reboot.
De souvenir plutôt que de recréer une nouvelle partition, je supprimais l’entrée de ma partition PV de ma table de partition pour la recréer avec le nouvel espace disque (nouveau dernier block), là c’était reboot obligatoire (partprobe pas suffisant car périph
occupé forcément). Ensuite redimensionnement du PV (pvresize), puis lvextend et resize2fs.
Si jamais ça peut aider.
Laurent
De : FRsAG [mailto:frsag-bounces@frsag.org]
De la part de Jean-Yves LENHOF
Envoyé : jeudi 28 mai 2015 07:48
À : frsag@frsag.org
Objet : Re: [FRsAG] Fwd: Agrandissement du disque dur d'une VM
Le 28/05/2015 05:53, Mrjk a écrit :
Hello,
Je cherche à agrandir le disque dur de mes VMs à chaud, mais ça ne fonctionne pas. Pour rappel, la procédure consiste à:
1) Agrandir l'image disque de la VM depuis l'hyperviseur (du qcow2 ici)
2) Aller sur la VM, et vérifier que la VM a bien détecté le changement de taille
3) Supprimer la partition LVM, puis la recréer avec la nouvelle taille
Jusque là, tout le monde est d'accord, sauf que je suis _systématiquement_ obligé de rebooter mes VMs, même après relecture de la table de partition. Le reboot fonctionne plutôt bien (quoique là j'ai un cas,
même après reboot, il veut pas se mettre à jour)
Évidement, le message qui revient tout le temps est le suivant (partprobe, sfdisk, blockdev, kpartx ...):
BLKRRPART: Device or resource busy
This disk is currently in use.
On voit bien que les nouvelles tailles sont prises en compte:
root@vmdb:~#cat /proc/partitions
major minor #blocks name
254 0 20971520 vda
254 1 195520 vda1
254 2 20775968 vda2 <== c'est lui 20775968 = 20Go, donc c'est bon
253 0 1048576 dm-0
...
Mais LVM, ba ... il s'en fou:
lo,
Tu as bien fait un pvresize sur le device /dev/vda2 ici ?
Ce serait peut-être bien si tu nous mettais l'ensemble des commandes tapées.
root@vmdb:~# pvs
PV VG Fmt Attr PSize PFree
/dev/vda2 systemvm lvm2 a-- 9.58g 416.00m <== et là, juste 9Go
Bon, reboot, et ça se règle, mais ça me gonfle ... Que faire pour que ça fonctionne à chaud ? Est-ce que vous avez le même problème? C'est aléatoire ? Faut modifier la conf de LVM ? Rajouter des arguments sur le kernel ... Je sais plus
où chercher pour le coup ...
Plus d'infos sur ma config:
#######################
Hyperviseur:
- libvirt/qemu-kvm
- Disques:
# pvs
PV VG Fmt Attr PSize PFree
/dev/vda2 systemvm lvm2 a-- 9.58g 416.00m
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 254:0 0 20G 0 disk
├─vda1 254:1 0 191M 0 part /boot
└─vda2 254:2 0 19.8G 0 part
├─systemvm-slash (dm-0) 253:0 0 1G 0 lvm /
├─systemvm-home (dm-1) 253:1 0 100M 0 lvm /home
├─systemvm-tmp (dm-2) 253:2 0 100M 0 lvm /tmp
├─systemvm-var (dm-3) 253:3 0 1G 0 lvm /var
├─systemvm-var_log (dm-4) 253:4 0 1000M 0 lvm /var/log
├─systemvm-swap (dm-5) 253:5 0 1G 0 lvm [SWAP]
└─systemvm-var_lib_mysql (dm-6) 253:6 0 5G 0 lvm /var/lib/mysql
JYL