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-boun...@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 4) Agrandir le PV 5) Jouer avec les LV ... 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 - Debian Wheezy VM: - Debian Wheezy - Disques: # pvs PV VG Fmt Attr PSize PFree /dev/vda2 systemvm lvm2 a-- 9.58g 416.00m # lblk 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 -- Robin Cordier JYL
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
